- 
                Notifications
    You must be signed in to change notification settings 
- Fork 209
Remove Package.resolved to reveal build errors caused by upstream changes #299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
46433d7    to
    69d5612      
    Compare
  
    | Github seems to be having having timeouts to download artifacts (which is screwing the protobuf CI step) | 
| I don't know what this would change, but couldn't hurt, could you rebase and see if CI is happier? @euanh | 
…nges Checking in `Package.resolved` for library packages is discouraged because it can mask failures caused by new versions of upstream dependencies. When `containerization` is built in CI, or when tests are run inside a checked-out local copy of the repository, `Package.resolved` pins all its dependencies to fixed versions. New versions of upstream dependencies wil not be tested unless `Package.resolved` is explicitly updated. When `containerization` is built as a dependency of a end-user project, its `Package.resolved` file is ignored. Instead, the dependency constraints from `containerization`'s `Package.swift` file are combined with those of the project and any other library dependencies, so SwiftPM or Xcode can find a set of mutually compatible packages. This can lead to new versions of `containerization`'s upstream dependencies being used, even though those versions have never been tested in CI. The effects of this can currently be seen, because `swift-nio` has changed upstream, breaking packages which depend on `containerization` but not breaking `containerization`'s own CI. `swift-nio` 2.86.1 removes the `NIOFileSystem` product (apple/swift-nio#3370) which is not yet ready to be public. CI builds of `containerization` are not affected by this change because `Package.resolved` pins `swift-nio` to an older version: { "identity" : "swift-nio", "kind" : "remoteSourceControl", "location" : "https://github.com/apple/swift-nio.git", "state" : { "revision" : "34d486b01cd891297ac615e40d5999536a1e138d", "version" : "2.83.0" } }, In comparison, creating a new package which uses `containerization` shows that the library can no longer be built: % swift package init --type executable Creating executable package: test Creating Package.swift Creating Sources Creating Sources/test/test.swift % cat > Package.swift <<EOF heredoc> // swift-tools-version: 6.2 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( name: "test", platforms: [ .macOS(.v26), ], dependencies: [ .package(url: "https://github.com/apple/containerization", from: "0.7.2"), ], targets: [ // Targets are the basic building blocks of a package, defining a module or a test suite. // Targets can depend on other targets in this package and products from dependencies. .executableTarget( name: "test", dependencies: [ .product(name: "Containerization", package: "containerization"), ] ), ] ) EOF % swift build ... /private/tmp/test/.build/checkouts/containerization/Sources/ContainerizationOCI/Client/RegistryClient+Fetch.swift:25:8: error: no such module 'NIOFileSystem' 23 | 24 | #if os(macOS) 25 | import NIOFileSystem | `- error: no such module 'NIOFileSystem' 26 | #endif 27 | Removing `Package.resolved` causes the same error to occur in a clean build of `containerization`.
69d5612    to
    e81f475      
    Compare
  
    | @dcantah Still timing out on the protobuf dependency download  | 
| If we want to try to keep reproducible builds, we should probably enable the  
 | 
Checking in
Package.resolvedfor library packages is discouraged because it can mask failures caused by new versions of upstream dependencies.https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/resolvingpackageversions#Coordinating-versions-of-dependencies-for-your-package
When
containerizationis built in CI, or when tests are run inside a checked-out local copy of the repository,Package.resolvedpins all its dependencies to fixed versions. New versions of upstream dependencies wil not be tested unlessPackage.resolvedis explicitly updated.When
containerizationis built as a dependency of a end-userproject, its
Package.resolvedfile is ignored. Instead, thedependency constraints from
containerization'sPackage.swiftfile are combined with those of the project and any other library
dependencies, so SwiftPM or Xcode can find a set of mutually compatible
packages. This can lead to new versions of
containerization's upstreamdependencies being used, even though those versions have never been tested
in CI.
The effects of this could be seen before #298 was merged, because
swift-niohad changed upstream, breaking packages which depend oncontainerizationbut not breaking
containerization's own CI.swift-nio2.86.1removed the
NIOFileSystemproduct (apple/swift-nio#3370)which is not yet ready to be public. CI builds of
containerizationwerenot affected by this change because
Package.resolvedpinnedswift-niotoan older version:
In comparison, creating a new package which used
containerizationshowed that the library could no longer be built:Removing
Package.resolvedwould cause the same error to occur in a clean build ofcontainerizationand be picked up in CI.