Clean up dependencies and imports. #1935
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: As we've largely completed our move to split out our core abstractions, we now have an opportunity to clean up our dependencies and imports. We should arrange for everything to only import NIO if it actually needs it, and to correctly express dependencies on NIOCore and NIOEmbedded where they exist. We aren't yet splitting out tests that only test functionality in NIOCore, that will follow in a separate patch. Modifications: - Fixed up imports - Made sure our protocols only require NIOCore. Result: Better expression of dependencies.
glbrntt
approved these changes
Aug 12, 2021
Co-authored-by: George Barnett <gbarnett@apple.com>
glbrntt
approved these changes
Aug 12, 2021
fabianfett
approved these changes
Aug 12, 2021
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
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.
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:
As we've largely completed our move to split out our core abstractions,
we now have an opportunity to clean up our dependencies and imports. We
should arrange for everything to only import NIO if it actually needs
it, and to correctly express dependencies on NIOCore and NIOEmbedded
where they exist.
We aren't yet splitting out tests that only test functionality in
NIOCore, that will follow in a separate patch.
Modifications:
Result:
Better expression of dependencies.