Introducing yet another swiftenv

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.

Welcome to try out and propose issues at GitHub.

1 Like


without having checked out your implementation, did you have a look at

1 Like

Actually not.

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!

Terms of Service

Privacy Policy

Cookie Policy