The State of Rust in MacPorts Today
kpreid at switchb.org
Wed Dec 14 01:30:34 UTC 2022
On Tue, Dec 13, 2022 at 7:50 AM Christopher Jones <jonesc at hep.phy.cam.ac.uk>
> … move to a model where the version is part of the port name, e.g. the
> current one would be called something like rust-1.61. ...
1. Add a shim port ‘rust’ which simply installs sym-links etc. to the
> ‘current best version’ that mimics the current installation, i.e. in the
> main prefix. If done well, users should then be blind to the changes above.
> 2. Users that want an older rust could explicitly depend on and use a
> specific versioned rust-N
A suggestion: if this is done, the shim port would ideally work in the same
fashion as the "rustup"  Rust installation manager tool does. That is,
the command shims are not just symlinks, but a binary that invokes the
chosen version, which can be overridden on a per-project or per-user basis
<https://rust-lang.github.io/rustup/overrides.html> , or at the command
line with a special command argument like cargo +1.61.0 build. The
advantage this gives users is that MacPorts-installed Rust will
automatically work with existing Rust projects which, for whatever reason,
wish to use a specific toolchain version, as well as typical advice in
Almost certainly, the simplest way to do this would be for the shim port to
actually itself be rustup, configured to know about the MacPorts-installed
I believe this should work seamlessly, other than perhaps configuring that
toolchain link and setting the default toolchain (which is essentially like
the port select mechanism in MacPorts) — which could be, at worst, a note
printed at installation telling the user to run the link and default
This would also allow users who wish to use Rust versions not packaged by
MacPorts to obtain rustup itself from MacPorts.
(rustup has a self-update mechanism, but I believe that can be disabled for
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-dev