A common complaint I see in discussions about using Swift on Linux is that it's not possible to install Swift through popular package managers and distributions besides Ubuntu. Why is this the case? Are there technical reasons behind this? Is there anything I can do to help improve the situation?
7 Likes
Volunteers are needed to build and maintain the packaging scripts, do the work to build and upload the packages to the repositories, etc.. Don't think it's a technical issue, just a resource issue. This is speculation, but, Ubuntu Linux may be special because Apple may use Ubuntu Linux on its internal server farms, or Canonical has stepped up and added support for Swift to Ubuntu. For whatever reason, Ubuntu Linux has been supported since Apple open-sourced Swift. Support for other Linux distros, FreeBSD, Windows, has come from the community.
1 Like
Expanding on the package managers for a moment: what is available via the Linux system package managers is determined entirely by those Linux communities. If there was a desire to have Swift in the Debian package tree, any Debian contributor can arrange to have that happen by volunteering to maintain the Debian packages.
However, based on some of the observed discussions around ABI stability, I want to make something clear. Shipping Swift in the standard system package tree will need to pin Swift to a specific compiler version on that distribution at that version. For example, consider Debian Buster, the upcoming stable Debian that will ship sometime this year. It was frozen in March, so the latest reasonable compiler version it could have packaged would have been Swift 5.0.0 (side note: that would have been bloody fast, it'd be more likely to have a 4.2 release, but I digress).
At this point, Debian Buster could never upgrade the Swift it ships past this level. This is because doing so would change the runtime copy of libSwiftCore, which would potentially break any application compiled on Buster. That's obviously unacceptable, and would not be tolerated by Debian.
Debian Buster will be the stable release for 2 years and supported for 3, meaning that for 2 years the only Swift version available on Debian would be 5.0. Nothing in 5.1 or any future release, which means no opaque result types, no function builders, nothing.
As always, it's helpful to be careful what you wish for. I think what most folks currently want is a one-click download of recent Swift snapshots appropriate for their platform. As @jonprescott made clear, this is fundamentally a resource issue that the community can address by setting up appropriate integration tools and contributing community CI.
7 Likes
And anyone looking at what the community may want here would be advised to look at Rust, where the rustup tool can manage installed Rust versions, including nightlies, and projects can declare their dependence on particular versions as well. Such a tool would help the installation story so that actual package stability isn't required.
4 Likes
I'm not familiar with rustup. How does it compare to a tool like pyenv or even swiftenv which manage python and swift versions respectively at both local (cwd) and global scopes?
Would it perhaps be more feasible/desireable to make something like swiftenv available in the Debian repositories?
1 Like
Once Swift has ABI stability, will this still be the case?
Swift already has ABI stability on Darwin platforms. What he’s describing is basically what ABI stability means for a platform.
1 Like
Swift is not officially ABI-stable on Linux. As part of preparing Swift for a distribution, a vendor or maintainer could choose to maintain a stable ABI for their platform, but they would need to take on that work, and it's a lot of work for what is likely to be little benefit, unless many people start also distributing binary-only resilient libraries on Linux. Overall, I think it'd be better to treat Swift like other ABI-unstable languages, as discussed upthread.
8 Likes
rustup has similar behavior to what you get from pyenv (I haven't used swiftenv but presumably similar?): it allows you to download any Rust toolchain you like, and then to specify a global default as well as overrides on a per-directory basis. Unlike pyenv (from what I recall), the overrides are stored in a single file in the user's rustup installation directory (default ~/.rustup/settings.toml), rather than in the override directory itself.
1 Like
Why is this needed with Rust? I thought backwards compatibility was a top priority for that project, so you should always be able to compile your code with the latest compiler.
New compiler versions are indeed strongly backwards compatible but introduce new features, improvements etc. as you’d expect… and, like any software project, also occasionally bugs!
Most users track latest stable, but some libraries set supported version ranges and the ability to specify versions means those developers can develop those projects against their supported version matrix. It also helps with letting people easily switch between stable, beta, and nightly releases.
That is basically what swiftenv does. You can put a .swift-version file in any directory to change the local swift version used in subdirectories of that directory and then there is also a global swift version used when there is no .swift-version file that sets the local version.
4 Likes
But that is Debian.
Debian is purposefully a conservative distribution for people who value stability over novelty.
This doesn't apply to faster-moving distros like Ubuntu, nor to rolling release distros like Arch.
And in fact, a common thing on Ubuntu is to have separate PPAs for packages that are not maintained by Canonical. Often, there's even an (older) version of some package in the official repositories and a PPA with more frequent updates. Similiary, Arch users have the official repositories as well as the AUR.
I think this is false. Linux users typically don't like "one-click downloads". Ideally, everything they install is installed through a package manager, so they can always keep track of all the software they have on their system, although for some shell utilities like the version managers mentioned below, install scripts also seem to work (the key point is that it's trivial to uninstall these by deleting a certain folder; for arbitrary software, this is much harder and hence why a package manager is preferred).
If you need a runtime for some program, I think many people are usually comfortable with using an install from the official repositories or from a PPA. Now, developers for the specific language will usually want to have some more control over the different versions of a language, so they might use tools like rbenv, pyenv, etc.
4 Likes
Sure it does. The only part that does not apply is the "two year" comment.
As Swift makes no guarantees about ABI stability on Linux, if you update your libSwiftCore at all, any previously compiled Swift programs are no longer guaranteed to work. This means that any update of the system via pacman risks breaking all existing Swift-based binaries and forcing a recompile. While this can happen on Arch with other language runtimes, in general it does not happen for all package updates, which would be the case for Swift.
Incidentally, the same thing applies to Ubuntu, which even though it is "faster moving" is frequently dominated by the 5-year-lifetime LTS installs.
Regardless, it has been said repeatedly in this thread that there is nothing stopping people from getting Swift into distribution package managers: it only takes volunteers to do it. All I was suggesting is that folks who want to apt-get install swift are quite probably not aware of the downsides of such an approach, and may want to consider an alternative distribution mechanism.
1 Like
I created and maintain the "official" Swift on Linux package for Fedora. If you're on a Fedora flavor of Linux, 5.0.1 is available via sudo dnf install swift-lang. I try very hard to have the latest released version of Swift available on Fedora as soon as it's available.
As far as the technical situation, Fedora adheres very much to the Linux Filesystem Standard so packages may not install anything is /usr/local, and because a Fedora user may install separately clang and lldb, which are not compatible with Swift (as Swift brings its own version), I have to patch the Swift source to relocate where the swift binary looks for lldb (normally in the same directory (i.e. bin), but in Fedora's case it's /usr/libexec/swift-lldb).
There was a thread here awhile back tossing around the idea of renaming the binaries to be prefixed with "swift" (e.g. swift-lldb) which would make packaging a lot easier, but as of 5.1 that hasn't happened.
As an aside, because the Swift toolchain is so big, it takes a long time to build from scratch, only to discover a packaging problem, or something fails to compile due to glibc version issues, kernel changes, whatever. Every version of Swift has had its own issues with Fedora requiring patches. Fedora, being a rapid-release flavor, definitely doesn't help here; I've had many issues that were simply because suddenly Fedora was using a new version of some core library where functionality had changed and Swift's C++ code wasn't expecting. Frankly I kinda enjoy the technical challenge and getting Swift compiled and running on Fedora has been a lot of fun.
As of right now, I have the latest Swift 5.1 beta packaged on Fedora, but the REPL isn't working and I'm still trying to figure out why. That is something I'd love some help with.
Ron
19 Likes
Minor update: I indeed got the REPL working with 5.1; I maintain nightly builds on my Fedora page for Swift if anyone wants to try Swift 5.1 on Linux (Fedora). Note that I have an automated job that will replace these files every time there's a new release.
3 Likes