Clean up dependency graph and imports #218
Merged
Conversation
This file contains 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: AWSLambdaRuntimeCore and MockServer both have dependencies on the NIO module, but they don't express this in their Package.swift: they implicitly rely on these dependencies being met by the NIOHTTP1 import. This was always brittle: it could lead to timing issues in the build that could lead to it failing. Modifications: - Correctly express the dependency on NIO in Package.swift - Correctly import _NIOConcurrency in files where it's used Result: Better and more accurate builds.
Lukasa
force-pushed
the
cb-fix-up-package-file
branch
from
2f31557
to
6ed1760
Compare
fabianfett
approved these changes
Aug 13, 2021
tomerd
added
the
patch-version-bump-only
Lukasa
added a commit
to Lukasa/swift-nio
that referenced
this pull request
Aug 16, 2021
Motivation: In apple#1935 I removed NIO as a dependency of a number of our library targets. This unfortunately led to some downstream breakage in modules that were (incorrectly) assuming they could import NIO without expressing a dependency on it in their Package.swift, e.g. swift-server/swift-aws-lambda-runtime#218. While a forums thread (https://forums.swift.org/t/semantic-versioning-should-removing-a-dependency-be-a-semver-major/51179) is ongoing to discuss the implications of this, we should re-add the dependency to undo the breakage against main. I've validated this locally: merely having the dependency is enough, we don't have to use it. Modifications: - Re-add NIO as a dependency to: - _NIOConcurrency - NIOFoundationCompat - NIOHTTP1 - NIOTLS - NIOWebSocket Result: Broken downstreams can build again.
This was referenced Aug 16, 2021
Lukasa
added a commit
to apple/swift-nio
that referenced
this pull request
Aug 16, 2021
Motivation: In #1935 I removed NIO as a dependency of a number of our library targets. This unfortunately led to some downstream breakage in modules that were (incorrectly) assuming they could import NIO without expressing a dependency on it in their Package.swift, e.g. swift-server/swift-aws-lambda-runtime#218. While a forums thread (https://forums.swift.org/t/semantic-versioning-should-removing-a-dependency-be-a-semver-major/51179) is ongoing to discuss the implications of this, we should re-add the dependency to undo the breakage against main. I've validated this locally: merely having the dependency is enough, we don't have to use it. Modifications: - Re-add NIO as a dependency to: - _NIOConcurrency - NIOFoundationCompat - NIOHTTP1 - NIOTLS - NIOWebSocket Result: Broken downstreams can build again.
fabianfett
pushed a commit
that referenced
this pull request
Aug 24, 2021
- Correctly express the dependency on NIO in Package.swift - Correctly import _NIOConcurrency in files where it's used
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
AWSLambdaRuntimeCore and MockServer both have dependencies on the NIO
module, but they don't express this in their Package.swift: they
implicitly rely on these dependencies being met by the NIOHTTP1 import.
This was always brittle: it could lead to timing issues in the build
that could lead to it failing.
Modifications:
Result:
Better and more accurate builds.