-
Option for disallowing binary dependencies: One such use case is mentioned here. With the intent being that the package author doesn't accidentally add binary dependencies, we could say this flag is ignored if the dependency is used transitively to resolve the overriding issue. I don't feel strongly about this flag, though. If the general consensus is that it doesn't provide enough value, we should drop it.
-
Checksum: relying on the tag seems to add much more complexity, especially if we want to provide an additional override. Are there any concerns with storing the checksum?
-
Manifest API: I like the suggested simplification, the current API has evolved from a more complex one and it seems good to clean that up since we removed that complexity from the proposal.
-
I don't think we should get into the business of verifying the contents of the XCFramework. If we think that's important, there are more conditions we should verify as well, such as whether the module name of the binary matches what is specified in the framework.
-
The type is actually an interesting question we hadn't considered, yet. Presumably
.automaticshould actually be an error and we should require the type to match whatever linkage the binary artifact uses. SwiftPM could then verify it, if we think that's important. -
I don't think ignoring dependencies makes sense and that seems unexpected. Ideally, we would have solved that through platform restrictions already. My expectation is that there's no special behaviour for non-Apple platforms, but instead we will enumerate what the artifacts provide and fail the build if there's no binary for the destination. This would cover both non-Apple platforms (where this would always fail today), as well as the case where the XCFramework doesn't contain a binary for the destination.