Remove NIOFileSystem from products #3370
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Motivation: NIOFileSystem has a few APIs which expose swift-system. We'll need to replace those before making this API stable. Modifications: - Remove NIOFileSystem product - Modify snippet so that it still builds Result: NIOFileSystem isn't yet public API
gjcairo
approved these changes
Sep 8, 2025
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
…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`.
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
swift-nio's public export of NIOFileSystem was removed in 2.86.1: apple/swift-nio#3370 NIOFileSystem was not yet supposed to be public, but _NIOFileSystem depended on it as a public import. This made it possible for `containerization` to see the `NIOFileSystem` package by accident. Replacing the use of `NIOFileSystem` by `_NIOFileSystem`, as used elsewhere, fixes the problem.
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
swift-nio's public export of NIOFileSystem was removed in 2.86.1: apple/swift-nio#3370 NIOFileSystem was not yet supposed to be public, but _NIOFileSystem depended on it as a public import. This made it possible for `containerization` to see the `NIOFileSystem` package by accident. Replacing the use of `NIOFileSystem` by `_NIOFileSystem`, as used elsewhere, fixes the problem.
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
swift-nio's public export of NIOFileSystem was removed in 2.86.1: apple/swift-nio#3370 NIOFileSystem was not yet supposed to be public, but _NIOFileSystem depended on it as a public import. This made it possible for `containerization` to see the `NIOFileSystem` package by accident. Replacing the use of `NIOFileSystem` by `_NIOFileSystem`, as used elsewhere, fixes the problem.
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
swift-nio's public export of NIOFileSystem was removed in 2.86.1: apple/swift-nio#3370 NIOFileSystem was not yet supposed to be public, but _NIOFileSystem depended on it as a public import. This made it possible for `containerization` to see the `NIOFileSystem` package by accident. Replacing the use of `NIOFileSystem` by `_NIOFileSystem`, as used elsewhere, fixes the problem.
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
swift-nio's public export of NIOFileSystem was removed in 2.86.1: apple/swift-nio#3370 NIOFileSystem was not yet supposed to be public, but _NIOFileSystem depended on it as a public import. This made it possible for `containerization` to see the `NIOFileSystem` package by accident. Replacing the use of `NIOFileSystem` by `_NIOFileSystem`, as used elsewhere, fixes the problem.
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
…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`.
jglogan
pushed a commit
to apple/containerization
that referenced
this pull request
Sep 23, 2025
swift-nio's public export of NIOFileSystem was removed in 2.86.1: apple/swift-nio#3370 NIOFileSystem was not yet supposed to be public, but _NIOFileSystem depended on it as a public import. This made it possible for `containerization` to see the `NIOFileSystem` package by accident. Replacing the use of `NIOFileSystem` by `_NIOFileSystem`, as used elsewhere, fixes the problem. ## Why does CI currently pass? The change in `swift-nio` does not currently cause `containerization`'s CI to fail because `Package.resolved` pins `swift-nio` to 2.83.0, before the change was made. New versions of upstream dependencies will not be tested until `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 build failure can be demonstrated by creating a new package which depends on `containerization` but does not constrain package versions: ``` % 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 | ```
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 23, 2025
…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`.
euanh
added a commit
to euanh/containerization
that referenced
this pull request
Sep 30, 2025
…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`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
NIOFileSystem has a few APIs which expose swift-system. We'll need to replace those before making this API stable.
Modifications:
Result:
NIOFileSystem isn't yet public API