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

Overwrite prompt of Use gets cancelled in non-interactive Linux environments #79

Open
vzsg opened this issue Oct 12, 2023 · 2 comments
Open

Comments

@vzsg
Copy link

vzsg commented Oct 12, 2023

When running swiftly use in a non-interactive environment, in my case a Heroku buildpack, the following section in the Linux implementation of use gets immediately cancelled: Linux.swift#L69-L86, and the symlinks are never overwritten.

My use case would greatly benefit from a --disable-confirmation flag, like the swiftly install script does, which would suppress the file list (it's noise) and would silently overwrite the symlinks.

@vzsg
Copy link
Author

vzsg commented Oct 13, 2023

Actually, a --force flag for might be even better, that would recreate the symlinks

  • even if the config JSON says that the current version is already in use
  • without confirmation

@patrickfreed
Copy link
Collaborator

The prompt being overridden here is a pretty important one--it's verifying that you're okay with overwriting existing third party tools with special versions that Swift bundles in its own toolchain. Doing so can be extremely disruptive, since these Swift-specific versions will not match the behavior of the old versions they're overwriting. That said, I can imagine this being useful in in containerized environments where you might only really care about Swift being installed and the existing executables don't matter, though this flag should still be used with extreme care.

If I recall, your use case was that you had a corrupt installation of swiftly and needed to overwrite the config.json file and dangling symlinks from a prior installation (due to #82). This should be a rare case that wouldn't be encountered in the course of normal usage (sans bugs), so I don't think we'll want to override the config.json with this. In the future, we may want to introduce a repair command or something like that to handle those cases.

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

No branches or pull requests

2 participants