Support installing multiple release channels

[SimonSapin]

Rust is going to have three release channels: stable, beta, and nightly. Each of them has its use (that’s why they exist), so it will probably be common to have more than one of them installed at the same time on the same machine (such as a developer’s laptop).

Currently, this it is possible to install multiple rusts at different locations, and set up the PATH and (since the [rpath removal]) LD_LIBRARY_PATH environment variables to pick one of them. However this is error-prone and not very convenient.

It would be better if multiple versions could be installed in the same "prefix" (e.g. /usr, where the default environment variables Just Work^®). Executables could have a suffix to distinguish them, for example /usr/bin/rustc (stable), /usr/bin/rustc-beta and /usr/bin/rustc-nightly. Other files would have to be namespaced somehow to avoid conflicts.

(Corresponding Cargo issue: rust-lang/cargo#967)

[pnkfelix]

Semi-related: I have been wondering whether we should start distributing a wrapper script for invoking bin/rustc that sets up the [DY]LD_LIBRARY_PATH and other environment variables appropriately.

I saw a user recently who untarred the tar.gz binary package and tried to copy bin/rustc into a different location. I advised them to "just install it globally", but I would prefer to have some support for the use case where you do not install the distribution into /usr/.... I have been maintaining my own private script for supporting this, but it would probably be good to determine what our general attitude is about this. (That is, if the team thinks we can stomach supporting a wrapper script, then I can work on making my own script more robust and making it distributable. If the team hates the idea of a wrapper script ... well, then that's unfortunate given that we've also discarded using rpaths...)

---

Update: Oh, the reason that this is related to this topic is that a wrapper script can be written to support multiple release channels, either by having multiple scripts that point to the different spots as necessary, or by having a single script that reflectively dispatches on $0, i.e. guessing based on whether we see beta or nightly in the script's name.

[steveklabnik]

There is endless precedence for this kind of tooling in the Ruby/Python
worlds, and it's quite useful.

[SimonSapin]

@steveklabnik, right. At some point we might also want to do this by version numbers (e.g. have Rust 1.3 next to 1.4) in addition to release channels.

[brson]

The obvious problem with putting a bunch of same-named libraries next to each other is that they are going to cause resolution conflicts. We might resolve that by attaching a unique id to each build of the compiler and associating every library with that build. That will have some impact on distributing binary libs (which presumably nobody does currently).

The docs are also going to cause naming conflicts as well as some of the other supplementary files.

Have to consider all the different ways of installing Rust and whether and how to make them all compatible with multi-rust.

[alexcrichton]

Note that our makefiles specify a 'extra filename' paramter to be mixed into all filenames:

rust/mk/main.mk

Line 18 in 7222ba9

CFG_FILENAME_EXTRA=4e7c5e5c

We could tweak that per-release channel in theory. The binaries themselves won't have it mixed in, though (just the libs).

[nodakai]

I agree with @pnkfelix . It should suffice to extract as many TAR archives as the user wish under the common "base" directory in a parallel manner. They can coexist and uninstalling one of them is as simple as rm -rf.

*nix

We can simply provide a wrapper shell script to choose one of multiple installations:

$ ls /tmp/rust/*
/tmp/rust/rustc*

/tmp/rust/rust-0.12:
bin/  etc/  lib/  share/

/tmp/rust/rust-nightly-2014-11-25:
bin/  etc/  lib/  share/

$ /tmp/rust/rustc hello-rust.rs && ./hello-rust
Hello, world!

#! /bin/sh

basedir=${0%/*}
rustdir=`ls -td $basedir/rust-* | head -n 1` # the simplest logic to choose one
if [ -z "$rustdir" ]; then echo "no installation found"; exit 10; fi
bindir=$rustdir/bin
libdir=$rustdir/lib

LD_LIBRARY_PATH=$libdir $bindir/rustc "$@"

We can enhance this wrapper following battle-tested tools such as rvm (Ruby), pyenv (Python), or nvm (Node.js) (Several similar tools exist for each language; I'm not claiming they are the best ones for their languages.)

To those who likes nitpicking: not setting $0 properly is caller's fault.

Windows

The idea is the same as the *nix case. Instead of $0, we can implement a wrapper executable which calls GetModuleFileName() to locate the base directory:

• http://stackoverflow.com/questions/4000877/how-can-i-get-the-current-instances-executable-file-name-from-native-win32-c

[pnkfelix]

@nodakai another option for Windows is a wrapper .bat script. You can use the variable %~dp0 which expands (~) into the drive (d) and path (p) for the batch file (%0). See also: http://stackoverflow.com/questions/5034076/what-does-dp0-mean-and-how-does-it-work

(I do not do much Windows hacking; I just remembered that we used a trick like this in the Larceny project: larceny.bat, and I think a batch file will be easier for end-users to modify/maintain than a wrapper executable.)

[SimonSapin]

Have to consider all the different ways of installing Rust and whether and how to make them all compatible with multi-rust.

It’s maybe not as essential that all of the ways to install support this, as long as some of them do.

In particular, the packages for Rust release and nightly in my distribution currently conflict, and I’d like them not to :) IMO it’s ok if packagers need to do a small amount of work (like passing the right configure flags) to make this happen.

[brson]

I have a project that supports installation of multiple Rusts https://github.com/brson/multirust. It depends a bit on the upcoming release channel and installer infrastructure.