The State of Rust in MacPorts Today

[Herby G]

Kevin Reid:

> A suggestion: if this is done, the shim port would ideally work in the
> same fashion as the "rustup" [1] Rust installation manager tool does.
>

A very solid idea. We need to focus on getting the rust-N ports into place
to start.

David Gilman:

> The thing blocking me, and probably anyone else in the project, from
> bumping the version, and also from testing/updating other ports, is
> that I don't have access to build machines with older MacOS X
> releases.
>

Do you need the older macOS environments just to test the Rust update, or
do you need them to build the bootstrap compilers for these environments?

Because if it's the former, then I think we should just move forward using
the buildbots.  We need to get the Rust 1.(X-1) bootstrap compilers built
and hosted somewhere, then verify that the latest Rust (1.66.0 as of now)
can be built in Github CI.  Once that works, we should just commit the
update and observe via buildbot status which macOS versions are failing,
and do our best to resolve each broken environment over time.

At this point, upgrading incrementally across environments makes more sense
than trying to verify it works in every single environment before updating.

On Tue, Dec 13, 2022 at 8:31 PM Kevin Reid <kpreid at switchb.org> wrote:

> On Tue, Dec 13, 2022 at 7:50 AM Christopher Jones <
> jonesc at hep.phy.cam.ac.uk> wrote:
>
>> … 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" [1] 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> [2], 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
> tutorials.
>
> 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 versions
> <https://rust-lang.github.io/rustup/installation/package-managers.html> [3].
> 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
> commands.
>
> 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 packaged versions.)
>
> [1]: https://rustup.rs
> [2]: https://rust-lang.github.io/rustup/overrides.html
> [3]: https://rust-lang.github.io/rustup/installation/package-managers.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20221215/3ca42e56/attachment.htm>