-
Notifications
You must be signed in to change notification settings - Fork 28
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
Swiftly proxies #155
base: main
Are you sure you want to change the base?
Swiftly proxies #155
Conversation
Add a design proposal for the new swiftly proxy system
Hijacking https://github.com/anders0nmat/swift-embedded-pm/pull/3/files Consider:
Or proxy CLI arguments that don't exist in swiftly to
(I just write Swift for fun, so take my suggestions with a grain of salt) |
@BrianHenryIE your feedback is appreciated, thank you.
It seems from the above patch that the end goal is to be able to invoke the llvm-ar executable from the current toolchain. I'm curious, why dig through the symlink to the real path using the
Providing a swiftly run subcommand is something that we can consider as an enhancement to the current swiftly design. We could allow someone to run any command that they want, not just the toolchain ones. The command runs where the PATH is set to the toolchain binaries with the highest precedence. Also, we can set certain environment variables like CC and CXX to the selected clang version.
We can put these ideas and more into #22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% convinced by this yet. I wonder how the core team would feel about the swift exe being hijacked by swiftly.
@@ -208,6 +216,10 @@ To use the latest installed main snapshot, leave off the date: | |||
|
|||
`swiftly use main-snapshot` | |||
|
|||
The use subcommand also supports `.swift-version` files. If version file is present in the current working directory, or an ancestory directory, then swiftly will update that file with the new version to use. This can be a useful feature for a team to share and align on toolchain versions with git. As a special case, if swiftly could not find a version file, but it could find a Package.swift file it will create a new version file for you in the package and set that to the requested toolchain version. | |||
|
|||
Note: The `.swift-version` file mechanisms can be overridden using the `--global-default` flag so that your swiftly installation's default toolchain can be set explicitly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather the default is the other way. ie use
edits global settings and you can change local settings with a --local
flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that there are advantage of having this local as the default. It encourages the sharing of the toolchain revision that the team is working with through discovery of this feature of swiftly. Also, this helps to tie into one of the values of using swiftly itself, which is how easily and flexibly you can switch toolchains.
In terms of precedence, git defaults to local over global for its configuration.
I'm curious what you think are the pitfalls of this approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I realised as I was writing this, there is previous art that defaults to local. It is more a preference on my behalf and how I'd use swiftly
I'm definitely interested to hear if there are opinions from the core team about this enhancement. I prefer to think of this as extending the semantics, not "hijacking" the toolchain itself. There are precedents for a proxy mechanism of a toolchain manager on top of the toolchain itself, such as |
DESIGN.md
Outdated
* The presence of a .swift-version file in the current working directory, or ancestor directory, with the required toolchain version | ||
* The swiftly default (in-use) toolchain set in the config.json by `swiftly install` or `swiftly use` commands | ||
|
||
In the first two cases, if there is no matching toolchain installed, swiftly will attempt to automatically install the requested toolchain and use it if the installation succeeeds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need a way to disable this. People with a bad network connection will not be wanting to download 900MB of swift toolchain just to build a project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'll update this since this has come up a few times. It could be a case of over automation. Instead, if there's no matching toolchain then the command fails. The swiftly install
with no arguments can be used to install the currently selected toolchain with the full capabilities of that subcommand, including post install script, etc. Also, it's clear that an error is related to the install operation itself since that is the request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we also have a command line option to ignore the .swift-version
file. This would make it easier for things like CI to test a library (which includes a .swift-version
file) against multiple swift toolchains
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think that this in this case the command-line selectors will take precedence over both the .swift-version file and the global default in-use toolchain from the config.json. The CI can do this to force specific toolchain(s):
swiftly install 5.10.1 # Install this specific toolchain
swift build +5.10.1 # Build with this toolchain
…ocation clarify the boundaries of the swiftly toolchain abstraction and elaborate on how to work around them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be interested to hear the core team's view on intercepting any calls to swift
. Node does a similar thing with nvm
IIRC so there's precedent, not that that's the best example of an ecosystem if there are any security concerns 😅
I would say that the +
syntax is not overly discoverable or intuitive, I'm not aware of any other tool that has this. I'd be more inclined to have an actual flag that can either be intercepted or called via swiftly run
etc.
Overall however I agree that having a mechanism for being able to run commands in Swift with different versions without having to constantly switch your local version is valuable and should be implemented
DESIGN.md
Outdated
|
||
Swiftly helps you to easily install different Swift toolchains locally on your account. It also provides a single path where you can run the tools in the currently selected toolchain. Toolchain selection is [configurable](#toolchain-selection) using different mechanisms. | ||
|
||
Note that swiftly is *not* a virtual toolchain in itself since there are cases where it cannot behave as a self-contained Swift toolchain. For example, there can be external dependencies on specific files, such as headers or libraries, far too many and variable between toolchain versions to be managed by swiftly. Also, for long-lived processes, there is no way to gracefully restart them without help from the client. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence needs some tweaking I think
Note that swiftly is *not* a virtual toolchain in itself since there are cases where it cannot behave as a self-contained Swift toolchain. For example, there can be external dependencies on specific files, such as headers or libraries, far too many and variable between toolchain versions to be managed by swiftly. Also, for long-lived processes, there is no way to gracefully restart them without help from the client. | |
Note that swiftly is *not* a virtual toolchain in itself since there are cases where it cannot behave as a self-contained Swift toolchain. For example, there can be external dependencies on specific files, such as headers or libraries, far too many variables between toolchain versions to be managed by swiftly. Also, for long-lived processes, there is no way to gracefully restart them without help from the client. |
Do you know a way to engage the core team on this? I'm also curious if there are any concerns or suggestions from there. The proxy idea has been mentioned in the forums a couple of times now, the last one points to this PR. I have received some feedback, but I don't know if any have been representative of the core.
Thank you, this is a fair observation. The proxy concept along with the In their documentation there is only a small mention of the special selector syntax: I think that this syntax can be discoverable in swiftly by providing (some) examples in the getting started guide, demonstrating how to use swiftly. In the swiftly steady state I imagine that the syntax won't be used very often as the toolchain will likely be selected with either the in-use global default for the user, or hopefully, the project's I can see the
I'm wondering, since this has come up a few times, if it might be worth providing both proxy capability and #22 at the same time in this PR to suit different preferences and use cases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally tend to prefer a subcommand over the +
syntax since swiftly isn't ubiquitous (yet 🙂) like rustup is, and so introducing swiftly-specific syntax to a non-swiftly binary invocation may cause confusion for non-swiftly users when they encounter someone else using it (or more frustratingly, compatibility issues in scripts and what not). That said, it is a generally useful syntax, so if the core team is supportive, then I don't have a problem with it.
To avoid blocking the work for this, I'd suggest we start with the more conservative swiftly run <toolchain>
or swiftly exec <toolchain>
command and then add the +
syntax later.
DESIGN.md
Outdated
For cases where the physical toolchain must be located, such as references specific header files, or shared libraries that are not proxied by swiftly there is a method to resolve the currently selected toolchain to its physical location using `swiftly use`. | ||
|
||
``` | ||
swiftly use --location |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps --print-location
? As it is, it looks like --location
affects use
in some way.
DESIGN.md
Outdated
@@ -60,7 +67,7 @@ A simple setup for managing the toolchains could look like this: | |||
|
|||
The toolchains (i.e. the contents of a given Swift download tarball) would be contained in the toolchains directory, each named according to the major/minor/patch version. `config.json` would contain any required metadata (e.g. the latest Swift version, which toolchain is selected, etc.). If pulling in Foundation to use `JSONEncoder`/`JSONDecoder` (or some other JSON tool) would be a problem, we could also use something simpler. | |||
|
|||
The `~/.local/bin` directory would include symlinks pointing to the `bin` directory of the "active" toolchain, if any. | |||
The `~/.local/bin` directory would include symlinks pointing to swiftly itself. When these binaries are run swiftly proxies them to the requested toolchain, or a default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to more clearly explain what "these binaries" refer to in this sentence.
Maybe @shahmishal can bring it up but this should probably be raised at the Platform Steering Group until whatever group will end up with ownership of this takes over them |
I think this is right. There are plans to add a third steering group in future (dubbed "Ecosystem") and this might fall under that rather than Platform, but I could see it going either way in this case so starting with the platform steering group is the right way to go for now. The first step is to write up a pitch and post it to the forums. That pitch should cover the pros/cons of the approach, and recommend one (with the others being alternatives considered). Then engagement on the merits can happen in that thread. That said, it's fine to hash out early ideas on a doc in this repo beforehand. Once the pitch has had some time to converge on a way forward, the platform steering group would take it up as a proposal. You don't need the steering group to pre-clear that pitch, though you might want to give them a heads up about it, so they can engage in it too since they'll ultimately be the ones deciding which way to go with this. Note that since Swiftly was ingested into swiftlang and so is part of the Swift project now, I don't see anything contentious about close integration between the swift launch tool and swiftly per se. But of course, the other tradeoffs cited in this thread about exactly how that integration actually works should be discussed. |
Thanks everyone for the discussion here. This has been really positive. I will change the shape of this PR in a couple of ways and see if this can be accomplished in the near term:
Please let me know if there are any concerns over this latest pivot. |
…new swiftly run command
Change the nature of the swiftly symlinks so that they point to the swiftly executable at install time. These do not change when new toolchains are used. Toolchain selection happens each time when the proxies are run. The proxies are created for a well-known set of toolchain binaries that are constant for a wide variety of toolchain versions and platforms. Add support for .swift-version files for toolchain selection. Update the use command so that it can point out which toolchain is in use based on context, such as swift version files that are located in the current working directory or above. The fallback selection comes from the global default configuration's 'inUse' setting. When querying for what's in use the global default is shown with the "(default)" tag. If the in-use toolchain is selected by a swift-version file the path to that file is displayed. Provide a print location flag to the use subcommand that can print the file path of the toolchain that is in use in the current context. When using a new toolchain, depending on whether a swift version is selecting the current one, update the swift version file with the selected toolchain version. If no swift version file can be located, attempt to create a new one at the top of the git worktree. If there is no git worktree, then fallback to updating the global default in the configuration. Provide a global default flag for the use subcommand so that only the global default in-use toolchain is considered and not any of the swift version files.
@swift-ci test macOS |
Out of curiosity, do you have an idea of how this would interact with xcrun? |
Swiftly's mechanisms for toolchain selection are entirely separate from xcrun. But, it will install toolchain packages in the user's volume, and those should be reachable with xcrun. |
…esult and centralized error messages
Provide a run command that allows arbitrary commands to be run in the context of the selected toolchain. Provide a one-off selection mechanism with a special syntax on the run command.
@swift-ci test macOS |
The macOS check is passing despite the failure:
|
@swift-ci test macOS |
@swift-ci test macOS |
macOS is still passing all of the tests:
|
With no arguments the install subcommand will install the currently selected toolchain from the `.swift-version` files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay!
DESIGN.md
Outdated
|
||
``` | ||
# Download and install the latest main snapshot toolchain and run 'swift build' to build the package with it. | ||
swiftly run swift build +main-snapshot +install |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be a bit overkill to support the install
command this way, since users can just run swiftly install main-snapshot
before running this command. At least for now, I'd support simplifying this so there's only one way to install a toolchain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, I'll remove this. It might have made more sense in the context of the original proxy proposal.
**--version:** | ||
|
||
*Show the version.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need this implemented separately. The user can just run swiftly run swift --version
if they want the Swift version, or swift use
to print the in use toolchain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a global flag coming from the argument parser, not an explicit option for the run subcommand. See the --help
below. The CLI reference generator that I wrote for swiftly could probably use a bit of refinement to skip over these special flags. It's very naive at the moment, but I think better than having to maintain our own reference manually.
Run a command while proxying to the selected toolchain commands. | ||
|
||
``` | ||
swiftly run <command>... [--version] [--help] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This docstring should mention the +
syntax as an option
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This documentation is generated using a plugin that inspects the argument parser. The +
syntax is specific to this subcommand and so the usage here doesn't pick this up as a typical flag, option, or argument. Hopefully the examples usages below capture how to use this syntax. Note that the +
isn't strictly required, so not knowing about it doesn't block naive uses of swiftly run
.
let contents = try? String(contentsOf: svFile, encoding: .utf8) | ||
|
||
guard let contents = contents else { | ||
return (nil, .swiftVersionFile(svFile, nil, Error(message: "The swift version file could not be read: \(svFile)"))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than returning a tuple, could we just throw this error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error is part of the tuple here because in some contexts the error is ignored, while others it is thrown.
For example, when swiftly use
is displaying the currently selected toolchain, or it is trying to find the swift version file to update with the used version it doesn't care if the file is well-formed, or not matching a toolchain that is currently installed. Whereas in other cases like the proxies or the swiftly run
that will interfere with the ability to run the command against a toolchain.
Sources/SwiftlyCore/Platform.swift
Outdated
// The toolchain goes to the beginning of the PATH | ||
var newPath = newEnv["PATH"] ?? "" | ||
if !newPath.hasPrefix(tcPath.path + ":") { | ||
newPath = ([tcPath.path] + newPath.split(separator: ":").map { String($0) }).joined(separator: ":") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rather than splitting and joining again, can we just concatenate tcPath
, ":"
, and newPath
?
Sources/Swiftly/Use.swift
Outdated
internal static func execute(_ toolchain: ToolchainVersion, _ config: inout Config) async throws { | ||
let previousToolchain = config.inUse | ||
/// Use a toolchain. This method can modify and save the input config. | ||
internal static func execute(_ toolchain: ToolchainVersion, _ globalDefault: Bool, _ config: inout Config) async throws { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we pass globalDefault
by keyword arg? It can be hard to remember what the lone boolean indicates at the callsites.
Sources/Swiftly/Use.swift
Outdated
} else if let newVersionFile = findNewVersionFile(), !globalDefault { | ||
try toolchain.name.write(to: newVersionFile, atomically: true, encoding: .utf8) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't think swiftly should be creating local .swift-version
files if they don't already exist, at least not without user-opt in. I think it's fine to update an existing one, but I imagine most users will have a single Swift version that they use for all of their projects, and swiftly automatically creating these files may be a bit annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I can change this over to a prompt to either go ahead and create a file that can be shared, or update the global default.
Sources/Swiftly/Use.swift
Outdated
var message = "Set the active toolchain to \(toolchain)" | ||
if let previousToolchain { | ||
message += " (was \(previousToolchain))" | ||
var message = "Set the used toolchain to \(toolchain)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"used" -> "in-use"
let proxyList = [ | ||
"clang", | ||
"lldb", | ||
"lldb-dap", | ||
"lldb-server", | ||
"clang++", | ||
"sourcekit-lsp", | ||
"clangd", | ||
"swift", | ||
"docc", | ||
"swiftc", | ||
"lld", | ||
"llvm-ar", | ||
"plutil", | ||
"repl_swift", | ||
"wasm-ld", | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit concerned about this--what if a new toolchain has a new executable not on this list? Or what if a toolchain doesn't have a executable on this list? Perhaps being concerned about that is too pessimistic, but it seems somewhat brittle to me. I can't think of any solutions off the top of my head given that we want to support selecting a toolchain via .swift-version
files, though. The only thing I can think of is requiring users to run swiftly use
to select the toolchain from the file, but that does seem quite un-ergonomic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea of the stable proxy allowed list came out of some necessity, which was to install the proxies at swiftly init time instead of toolchain installation time, but also as a measure of security, which strongly favours allow lists over deny lists.
I can imagine that the commands in this list can be useful to someone in the context of swiftly. We can change this list over time, and manage the proxy symlinks as we do upgrades from version to version. If anyone has suggestions on adding/removing commands from the list I'm interested in hearing your opinions.
This is also one of the reasons that I updated the swiftly design document to clarify that the purpose of swiftly is not to be a fully virtual toolchain. Not all clients of the toolchain will be able to work within the abstraction that swiftly provides. In one case there is a need to reach inside and grab a dylib (.so). There are potentially many others where someone would like to reach in for a particular header file, or other resources. Swiftly isn't equipped to symlink, or proxy, everything in there. It's just not practical.
So, for cases where someone needs access to something more obscure, there is the escape hatch of the swiftly use --print-location
to get at the real toolchain path where they can reach into the internals as needed at the cost of being optionally dependent on swiftly for that capability.
…swiftly install`. Guard automatic creation of .swift-version file from `swiftly use` around a prompt overridable using an `--assume-yes`. Minor cleanup
Fix all of the swift.org urls so that they use www.swift.org to avoid redirection
@swift-ci test macOS |
The macOS tests are all passing with this latest commit:
|
The RHEL 9 tests failed on a network failure, otherwise everything passed. |
DESIGN.md
Outdated
|
||
`swiftly install` | ||
|
||
If no swift version file can be found then the installation fails indicating that it couldn't fine the file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very small nit, but could we use
If no .swift-version file ...
Rather than
swift version file
Just to be consistent, so users don't conflate the "swift version file" with something else in the Swift ecosystem. This way we explicitly mention the file in question. This is how it's written in the "Installing the version from the .swift-version
files" section
DESIGN.md
Outdated
@@ -208,6 +223,10 @@ To use the latest installed main snapshot, leave off the date: | |||
|
|||
`swiftly use main-snapshot` | |||
|
|||
The use subcommand also supports `.swift-version` files. If version file is present in the current working directory, or an ancestory directory, then swiftly will update that file with the new version to use. This can be a useful feature for a team to share and align on toolchain versions with git. As a special case, if swiftly could not find a version file, but it could find a Package.swift file it will create a new version file for you in the package and set that to the requested toolchain version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use subcommand also supports `.swift-version` files. If version file is present in the current working directory, or an ancestory directory, then swiftly will update that file with the new version to use. This can be a useful feature for a team to share and align on toolchain versions with git. As a special case, if swiftly could not find a version file, but it could find a Package.swift file it will create a new version file for you in the package and set that to the requested toolchain version. | |
If a .swift-version file |
Simple wording change suggestion
@@ -53,6 +53,10 @@ Likewise, the latest snapshot associated with a given development branch can be | |||
$ swiftly install 5.7-snapshot | |||
$ swiftly install main-snapshot | |||
|
|||
Install whatever toolchain is current selected, such as a .swift-version file: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Install whatever toolchain is current selected, such as a .swift-version file: | |
Install whatever toolchain is currently selected, such as a .swift-version file: |
*Run a command while proxying to the selected toolchain commands.* | ||
|
||
|
||
Run a command with a selected toolchain, so that all toolchain commands are become the default added to the system path and other common environment variables. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The wording of this sentence confuses me a bit, might just need some reworking
Sources/Swiftly/Install.swift
Outdated
@@ -39,9 +39,13 @@ struct Install: SwiftlyCommand { | |||
|
|||
$ swiftly install 5.7-snapshot | |||
$ swiftly install main-snapshot | |||
|
|||
Install whatever toolchain is current selected, such as a .swift-version file: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Install whatever toolchain is current selected, such as a .swift-version file: | |
Install whatever toolchain is currently selected, such as a .swift-version file: |
} else { | ||
// If there are no more toolchains installed, just unuse the currently active toolchain. | ||
try Swiftly.currentPlatform.unUse(currentToolchain: toolchain) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still want to unuse
the toolchain if there are no more toolchains to be set active, in order to clean up all the symlinks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this change the proxy symlinks are created at install time of swiftly and remain there. Keeping them stable helps with certain shells that aggressively cache commands on the PATH, such as zsh. If there are no toolchains installed and someone tries to run "swift", "clang", or some other toolchain command then swiftly will give an error indicating that they can install one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting, so by installing swiftly then you wouldn't really be able to invoke your original swift toolchain installation?
Say I had a toolchain installed, then I decide to install swiftly, I download some toolchains with swiftly, then ultimately uninstall them all. I then go to invoke swift again under the assumption my default toolchain which was installed prior to swiftly would take precedence. Sounds like in this case that would not work because all the symlinks would still be proxying through swiftly which wouldn't be able to find a toolchain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, by installing swiftly you're giving it the ability to control which toolchain you are invoking. Note that since swiftly maintains its own record of toolchains it installed, any that you've installed previously wouldn't be known to swiftly since they could be in virtually any location on the system.
The user can take control temporarily by overriding their PATH to the external toolchain that they want to use, or uninstall swiftly.
Fix symlink target selection for swiftly when it is system managed
@swift-ci test macOS |
Note that macOS CI is failing in a way that is unrelated to the tests. The tests are all green:
|
@swift-ci test macOS |
@swift-ci test macOS |
Add a design for the new swiftly proxy system for more flexible routing of command invocations to a toolchain.
Re-target the symbolic links that swiftly creates to point to swiftly itself, which can decide the selected toolchain more flexibly on a per-invocation basis.
Add support for reading the toolchain version from a
.swift-version
file if a selector isn't given. Theswiftly use
command will attempt to update a swift version file, or in certain circumstances it will create the version file for you. The specialswiftly install
with no selector argument that will attempt to install a toolchain version specified in a version file.Create a
swiftly run
subcommand that can run arbitrary commands, such as build scripts or makefile generators. This subcommand will set the PATH environment variable to the currently selected toolchain, and other special environment variables like CC and CXX to specifically point to the clang and clang++ executables. Add an ability for this subcommand to accept arbitrary toolchain selectors that take the higher precedence over the presence of the swift version file or the global default.Update
swiftly use
andswiftly list
to take into account that there is a global default, which is the fallback if there is no.swift-version
file, but also a potentially different toolchain that is in use in the current context. Theswiftly use
subcommand with not arguments will show in brackets the reason why the current in-use toolchain is selected, whether it is a special.swift-version
file in which case it will show the file path, or it is the global default.