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

Make updates better and more resilient #245

Merged
merged 3 commits into from
Mar 11, 2025

Conversation

cmcgee1024
Copy link
Member

No description provided.

Put a check in-place to unset the global default toolchain if it is no longer installed

Set the global default to the installed toolchain if it is not set

Add full toolchain selection resolution to the update operation resolve update parameters

Fix the use command and toolchain selection routine to consider a global default set to a toolchain that is not installed as no selection at all

Add check for the physical presence of a toolchain to proxy so that it prevents circularity errors and provides an actionable message
@cmcgee1024 cmcgee1024 changed the base branch from main to release/1.0 March 7, 2025 20:57
@cmcgee1024 cmcgee1024 marked this pull request as ready for review March 7, 2025 21:36
@cmcgee1024
Copy link
Member Author

TODO: update the main branch with these fixes

Add test cases

Control verbosity of uninstall operation on macOS and other platforms
@cmcgee1024
Copy link
Member Author

@swift-ci test macOS

var installedToolchains = startingConfig.listInstalledToolchains(selector: selector)
// This is in the unusual case that the inUse toolchain is not listed in the installed toolchains
if let inUse = startingConfig.inUse, selector.matches(toolchain: inUse) && !startingConfig.installedToolchains.contains(inUse) {
installedToolchains.append(inUse)

Choose a reason for hiding this comment

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

are we going to allow swiftly then to be able to uninstall toolchains it didn't have a hand in installing?

Copy link
Member Author

Choose a reason for hiding this comment

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

If the toolchain is in the inUse property of the config.json then it probably did have a hand in installing the toolchain at some point in time. This includes it in the list of installed toolchains for the purposes of the uninstall command. Below swiftly will expunge it from the config, and try once again to remove it from disk.

try await Use.execute(version, globalDefault: false, &config)
}

// We always update the global default toolchain if there is none set. This could
// be the only toolchain that is installed, which makes it the only choice.
if config.inUse == nil {

Choose a reason for hiding this comment

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

do we only want to do this when the user passes --use to install? In other words if --use was omitted does this still make sense?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think that it will be good to try and set a default global toolchain whenever we can to help users avoid cases where there's no default toolchain to fallback. It's an extra annoyance that most people probably don't care to have.

"Give me some kind of a swift toolchain please. I know that I have at least one installed in there."

// Check to ensure that the global default in use toolchain matches one of the installed toolchains, and return
// no selected toolchain if it doesn't.
guard let defaultInUse = config.inUse, config.installedToolchains.contains(defaultInUse) else {
return (nil, .globalDefault)

Choose a reason for hiding this comment

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

Just to confirm: You shouldn't be able to select a toolchain that wasn't installed by swiftly?

Copy link
Member Author

Choose a reason for hiding this comment

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

This should be a rare case, caused by things like improper handling of the update operation that this PR should solve. Another potential case is race conditions. This is pure hardening of the code, and also giving the user a way back to a nominal state by using a toolchain that is in the list that swiftly installed.

Copy link

@justice-adams-apple justice-adams-apple left a comment

Choose a reason for hiding this comment

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

LGTM!

@cmcgee1024 cmcgee1024 merged commit 5a0b96b into swiftlang:release/1.0 Mar 11, 2025
19 checks passed
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