swiftenv is an environment manager of Swift on Ubuntu at a very early stage, inspired by pyenv. It’s written in purely bash script and has so far supported to install and manage multiple versions of Swift and expose one of them to the system.
Why swiftenv?
Since Swift has not implemented complete backward compatibility yet, it’s still necessary for developers to test their code using different Swift versions. On macOS, xcrun can select the designated toolchain, while on Linux, developers still need to manage different paths manually. swiftenv can let developers easily switch between Swift versions in an easy way.
Also, it’s a little bit complicated to manually install Swift on Ubuntu. Before Swift gain community-hosted apt repository support or being officially adopted by Ubuntu, swiftenv might be among the easiest ways to install Swift on Ubuntu.
How to evolve?
swiftenv is currently based on scanning directories and files, thus does not support integrity check. There may be some tricky bugs to deal with, which largely relies on your tries and issues. man files and help command need to be implemented. Also, I hope development builds can be supported. These are the things to do before the 1.0 release.
For 1.x, I’d planned to support project-based Swift version config and introduce a new way to switch through Swift versions, which may works like pyenv. As long as community support is ready, Linux distributions besides Ubuntu can get swiftenv support too.
It seems that one has already had a bunch of users, and shares quite similar APIs (pyenv-like). I just found it probably a fork from pyenv, while I just work from the ground up.
I build my work for these main purposes, which are slightly different from Kyle’s:
Lightweight. Use single-file executable which can be easily installed or use as a script without any config.
Specific for platforms excluding macOS. I personally suggest using toolchains and xcrun on macOS, whose installation and usage are quite mature.
Unaffected by environment variables, which is likely to differ between shells on the same system. Swift itself doesn’t rely much on ENV too.
Keeps system-wide versions by sudo and allows local toolchains at the same time. This allows sudoers to install and config Swift for its users.
Independent of any self-hosted APIs. Use only official website to retrieve package information.
If necessary, it’s definitely okay to have another name since it’s at an early stage, and has different design purposes from the existing one. Also, I’ve wondering if Kyle is still maintaining the project, as the last commit is from nearly a year ago.
To conclude, I believe the two project can evolve in parallel, and I’m trying to make my project more Swifter-friendly instead of keeping the pyenv style. That is the point.
Absolutely! It's always good to have variety. Especially since you have great goals set for your project. A different name would be beneficial though I think, as not to confuse users.
Good luck with it and, mostly, have fun!
@stevapple Thanks for sharing this! Are there any plans to use anything other than shell scripts? Both swiftbox and swiftenv are implemented as shell scripts, and that is the biggest problem with them. None of this will work on Windows, or any other platform without bash.
Also, are there any plans to be able to install SDKs separately from the toolchain? It would be great if one could install a macOS toolchain and then only Linux and Android SDKs for cross-compilation purposes.
rustup is the best model here in my opinion. It's self-contained, available everywhere, and supports installing additional components separately from toolchains. I hope that Swift has a tool like that at some point. This would greatly increase its adoption, in my opinion.
I develop swiftbox (formerly swiftenv) based on what swift.org provides. This means that I can deal with Windows support only after swift.org provides official Windows toolchain packages. I think swiftbox for Windows may need a parallel Powershell version, and I’ll do that. Things are also the same with other Linux distributions. All the supported distributions include bash, so I use it directly.
Things are the same for SDK. Since swift.org does not provide standalone SDKs, swiftbox cannot install it directly. I wish the team can provide them too.
Thanks for your feedback! I’ll take a look at rustup once I have time.
Wouldn't it be easier if swiftbox itself was developed in Swift, the same way that rustup is developed in Rust? Then a separate version in PowerShell for Windows wouldn't be needed. It would also be a great demonstration of how Swift works as a cross-platform scripting and systems language.
Since this model needs to use shim, which swiftbox won’t adopt until 1.0, I’ll take it into consideration when deciding the structure of swiftbox 1.0. However, I don’t think it is suitable for swiftbox, because one of the core concepts of swiftbox is single-file.
rustup-init.sh installs Rust from official sites with a shell script, like swiftbox get does with Swift. Again, rustup utilizes Rust’s wide official operating system support, while Swift only supports three Linux distributions. A Swift toolchain manager in Swift will also be limited by this problem.
Maybe you can discuss in a new topic on whether to develop official toolchain management tool in Swift. That’s an awesome idea, isn’t it.
