Skip to content
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

Support different toolchains per folder #1478

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

plemarquand
Copy link
Contributor

With the introduction of swiftly's .swift-version file the active toolchain can now be per-folder instead of global. If the user has multiple different packages open they may each be using a different toolchain as defined by their .swift-version file.

In order to support this new paradigm the toolchain has been moved from WorkspaceContext to FolderContext. Each time a folder (package) is added to the workspace a new toolchain is created, as it might be different from folder to folder.

The toolchain created respects the .swift-version file. If the toolchain specified in the .swift-version file is not installed an error message is shown prompting the user to install the version with swiftly.

There is still a globalToolchain on the WorkspaceContext which refers to the globally available toolchain. This would be the toolchain used when you run swift outside of a workspace folder. This is mainly used as a fallback toolchain for when there are no workspace folders.

It is generally advisable to use the toolchain provided on the FolderContext to ensure you don't end up using mismatched versions.

This PR also refactors the LanguageClientManager so that one instance of sourcekit-lsp is started per-toolchain, coordinating startup so that the server from a given toolchain starts up when a folder using that toolchain is added to the workspace.

While this PR adds support for .swift-version files, there is still quite a bit of work to do to make using swiftly with the VS Code Swift extension a nicer experience including: Installing swiftly directly from the extension, downloading missing toolchains automatically, listing/picking/downloading toolchains via swiftly list, a smoother toolchain switching experience that would optionally write the .swift-version file, and more.

@plemarquand plemarquand force-pushed the toolchain-per-folder branch 2 times, most recently from 635a376 to bf2f81e Compare April 3, 2025 13:00
@plemarquand plemarquand marked this pull request as ready for review April 3, 2025 18:10
@plemarquand plemarquand force-pushed the toolchain-per-folder branch from 4b5b441 to 205dd97 Compare April 4, 2025 20:49
Copy link
Member

@cmcgee1024 cmcgee1024 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks good from my perspective. I'm not sure about the vscode specifics, and the failing test.

With the introduction of swiftly's `.swift-version` file the active
toolchain can now be per-folder instead of global. If the user has
multiple different packages open they may each be using a different
toolchain as defined by their `.swift-version` file.

In order to support this new paradigm the `toolchain` has been moved
from `WorkspaceContext` to `FolderContext`. Each time a folder (package)
is added to the workspace a new toolchain is created, as it might be
different from folder to folder.

The toolchain created respects the `.swift-version` file. If the
toolchain specified in the `.swift-version` file is not installed an
error message is shown prompting the user to install the version with
swiftly.

There is still a `globalToolchain` on the `WorkspaceContext` which
refers to the globally available toolchain. This would be the toolchain
used when you run `swift` outside of a workspace folder. This is mainly
used as a fallback toolchain for when there are no workspace folders.

It is generally advisable to use the toolchain provided on the
`FolderContext` to ensure you don't end up using mismatched versions.

This PR also refactors the `LanguageClientManager` so that one instance
of sourcekit-lsp is started per-toolchain, coordinating startup so that
the server from a given toolchain starts up when a folder using that
toolchain is added to the workspace.

While this PR adds support for .swift-version files, there is still
quite a bit of work to do to make using swiftly with the VS Code Swift
extension a nicer experience including: Installing swiftly directly from
the extension, downloading missing toolchains automatically,
listing/picking/downloading toolchains via `swiftly list`, a smoother
toolchain switching experience that would optionally write the
`.swift-version` file, and more.
@plemarquand plemarquand force-pushed the toolchain-per-folder branch from 205dd97 to 312b629 Compare April 9, 2025 15:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants