Update swift-tools-version to 6.0 #8404
Conversation
Because SwiftPM now relies on both `swift-build` and `swift-testing`, which require a 6.0 to build, the swift-tools-version in the Package.swift should reflect this requirement and be updated to 6.0.
plemarquand
requested review from
bnbarham,
MaxDesiatov,
jakepetroules,
xedin,
dschaefer2,
shawnhyam,
bripeticca,
owenv,
bkhouri,
cmcgee1024 and
daveyc123
as code owners
|
While we're bumping this up, can we add a |
.swift-version
Outdated
| @@ -0,0 +1 @@ | |||
| 6.0.3 | |||
There was a problem hiding this comment.
What's the purpose of this file? Do any of the tools support it?
There was a problem hiding this comment.
Swiftly supports this file, and I think SwiftFormat too. In the former case, it can use this information to automatically use the adopted toolchain for the project, or prompt the user to install it if they don't yet have it on their system. Here's a section of documentation that goes over how the sharing works: https://swiftpackageindex.com/swiftlang/swiftly/main/documentation/swiftlydocs/use-toolchains#Sharing-recommended-toolchain-versions
There was a problem hiding this comment.
Is there a reason we have to duplicate this information in both Package.swift and this additional file? Why not just parse // swift-tools-version in Package.swift instead?
There was a problem hiding this comment.
They serve two different purposes. The comment at the top of the Package.swift determines semantically what version of the swift-tools should be used to interpret the package metadata. The .swift-version file specifies a version of the physical toolchain that is known to work with the package.
There was a problem hiding this comment.
Sure, but wouldn't a physical toolchain known to work with the package be able to interpret package metadata, and thus they're interchangeable in a way?
My main objection is that we have too many undocumented places to specify compatible toolchains and modes. IIUC we have no centralized place to document this either. Adding one more file that duplicates essentially the same information and only has documentation for it in a separate package is not discoverable at all. This only makes things more confusing for contributors.
There was a problem hiding this comment.
Swiftly supports this file, and I think SwiftFormat too.
What does SwiftFormat do with it BTW? Does it determine semantic version of Swift to reformat the package, or does it install the physical toolchain matching the version? If the former, it seems to be doing the opposite of what Swiftly does, which exacerbates the confusion.
There was a problem hiding this comment.
Sure, but wouldn't a physical toolchain known to work with the package be able to interpret package metadata, and thus they're interchangeable in a way?
Not exactly.
In the way of an analogy there is also a swift (language) mode setting for targets. These indicate what versions of the language the compiler should use to interpret the code. Any number of toolchains with Swift compilers can satisfy the requirement of the Swift code to be compiled in that way. It's the same thing with the swift-tools-version that indicates how the package metadata should be interpreted. That doesn't indicate a specific toolchain version to use for the project. There is no version 999.0.0 toolchain you can download, for example.
Picking a particular toolchain version to use for the project is where the .swift-version file comes in. That will indicate the actual toolchain to install and use to work with the project for the greatest chance of success and stability in the features that are available in the standard libraries, command-line capabilities in SwiftPM, testing capabilities, etc., etc. It also helps to state that the project is tested rigorously (someday) with that version.
There was a problem hiding this comment.
Either way, this reasoning is new to me and I expected would also be new to the majority of our contributors. At the very least, the purpose of these different ways to specify versions of the toolchain should be clarified in CONTRIBUTING.md. I also hope that .swift-version supports comments, so that a link to relevant documentation is put there directly for easier discoverability.
There was a problem hiding this comment.
I also hope that .swift-version supports comments, so that a link to relevant documentation is put there directly for easier discoverability.
It does not support that because the intent is to make it very simple to use, even at shell scripting level. For example:
/install/location/swift-$(cat .swift-version)/usr/bin/swift test
There was a problem hiding this comment.
Also, having a .swift-version will allow us to eventually hook up the pipeline to use this toolchain version of swift, which would avoid PR such as #8408.
Having a .swift-version also move the needle a bit closer towards a hermetic build.
|
If |
Sure thing, that makes sense. I can take an action on that. Then we can link to the swiftly documentation on the topic. The hope is to eventually have the CI system read these files to decide which toolchain should be used, so it's more than just documentation, having a real impact on the CI. Swiftly has some documentation on that and self-hosts on this idea with GH actions. Meanwhile, my swiftly installation will use the correct toolchain for this project at all times. |
|
@cmcgee1024 @MaxDesiatov I've backed out the addition of |
|
@swift-ci please test windows |
|
@swift-ci please test macos |
1 similar comment
|
@swift-ci please test macos |
Because SwiftPM now relies on both
swift-buildandswift-testingand these both require Swift 6.0 to build, the swift-tools-version in SwiftPM's Package.swift should reflect this requirement and be updated to 6.0.