Skip to content

Conversation

@Kogia-sima
Copy link

Description

This PR adds support for Rust programming language.

Due to version management mechanism of Rust, this script allows installing multiple versions for a single directory. Second argument (installation directory for rustup) is for the compatibility with another languages.

Example

$ rust-install -h
[usage] rust-install [-f] VERSION [location]
  ex: rust-install 1.45.0
  ex: rust-install 1.45.0 ~/local/rust-1.45.0
$ rust-install 1.45.0 ~/local/rust-1.45.0
Start to install rust 1.45.0 ...
rust 1.45.0 successfully installed on /home/xbuild/local/rust-1.45.0
To use this rust, do 'export PATH=/home/xbuild/.cargo/bin:$PATH' and 'export RUSTUP_HOME=/home/xbuild/local/rust-1.45.0'.
$ export PATH="/home/xbuild/.cargo/bin:$PATH"
$ export RUSTUP_HOME=/home/xbuild/local/rust-1.45.0
$ rustc --version
rustc 1.45.0 (5c1f21c3b 2020-07-13)
$ rust-install 1.45.0 ~/local/rust-1.45.0
rust 1.45.0 already installed.
To do force re-install, use '-f' option
$ rust-install -f 1.45.0 ~/local/rust-1.45.0
Start to install rust 1.45.0 ...
rust 1.45.0 successfully installed on /home/xbuild/local/rust-1.45.0
To use this rust, do 'export PATH=/home/xbuild/.cargo/bin:$PATH' and 'export RUSTUP_HOME=/home/xbuild/local/rust-1.45.0'.

@tagomoris
Copy link
Owner

Thank you for proposing this change!
But I have a concern about merging this change. The concept of xbuild is to switch language versions by setting PATH, without any other switching mechanism.
I can understand that Rust has its own default version management toolchain, but installing Rust on it should cause inconsistent situations... Rust via xbuild needs the version management setting in addition to setting PATH.
(I guess it happens because people don't think installing Rust toolchains on production systems, but just install product binaries)

My preferable idea is to bypass rustup, but still not sure.
@Kogia-sima What do you think?

@Kogia-sima
Copy link
Author

@tagomoris Thank you for taking time to look down this feature.

There are two methods to execute Rust compiler (rustc):

  1. $CARGO_HOME/bin/rustc
  2. $RUSTUP_HOME/toolchain/<toolchain name>/bin/rustc

Both methods depend on RUSTUP_HOME environmental variable. Only way to control Rust version only by PATH variable is adding the directory of each toolchains ($RUSTUP_HOME/toolchain/<toolchain name>/bin) to PATH directly. This is possible, but also makes almost all of rustup features unavailable (such as default toolchain, toolchain overriding for local directory etc.).

Could you clarify the reason why xbuild is going to control language versions only by PATH vairable? I see little difference between setting PATH and changin RUSTUP_HOME variable (or run rustup default command).

P.S.

I'd like to propose another option.

  1. When installation directory is not specified, toolchain will be installed in RUSTUP_HOME.
  2. When installation directory is specified, toolchain will be install in RUSTUP_HOME, and symlink to the installed toolchain will be created at the specified path.

When user specified the installation directory, Rust version will be changed by setting PATH to the directory. No other operation is needed.

@tagomoris
Copy link
Owner

My original motivation is described here (only in Japanese). The main intention is to get rid of *env and *brew from production environments (those were used only to install language runtimes). This concept also helps to switch language versions very easily and clearly.

On the other hand, Rust initially integrates multiple version installation and version switching.
What's the main motivation to support it on this tool xbuild?

@Kogia-sima
Copy link
Author

I'm writing Dockerfile for our development server. We are using xbuild because it is a great tool for installing multiple languages on thre remote service. Today we also need Rust runtimes for only compiling and running the Rust code (this code launches the API server). Also we would like to update language versions when the toolchains are updated.

@tagomoris
Copy link
Owner

Finally, I got a conclusion to merge this change as-is. This tool should do things as less as possible, and if Rust requires setting an additional env variable, Rust users should know that. Unusual workarounds may cause unexpected behaviors for those people.
@Kogia-sima It should be good for you too, right?

@batara666
Copy link

Why would you support a Rust? rust already pre-installed on many os'es

@s-aska
Copy link

s-aska commented May 28, 2023

@batara666
Here is a summary of the reasons why a software developer would like to install multiple programming languages on their operating system:

They want to utilize the latest version of Rust.
They received bug reports related to a library they developed and want to reproduce the issues in the same Rust version for accurate debugging.
They prefer not to modify the pre-installed version of Rust on the operating system to avoid potential conflicts or disruptions.

I hope this information proves useful.

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

Successfully merging this pull request may close these issues.

4 participants