Re: Revisiting native rust

[Jan Danielsson <jan.m.danielsson%gmail.com@localhost>]

On 2024-07-23 12:20, Havard Eidnes wrote:
> >     [...] Just to be clear, installing a specific version is
> >     extremely easy, and just requires running a single command
> >     (assuming one has rustup installed already):
> >
> >     $ rustup install 1.67.0
>
> I'll admit that I've not fully understood the attraction of
> "rustup" (which we probably don't support at the moment for "our
> own" targets, which basically means != amd64).  Why is it that
> every language grows a package manager replacement of their own?

   In addition to what Jonathan Perkin noted (having immediate access 
to latest versions)..

   Projects that decide to create their own package managers may have 
special requirements that general purpose package managers aren't really 
designed to handle.  As I noted before, we pin stable versions of the 
Rust toolchain when we release new version of our embedded products. 
And at times, for experimental projects, I've pinned specific nightly 
versions.

   That is not to say I'm a fan of having multiple package managers, 
but it just so happens that rustup has, at least for me, been 
uncomplicated -- it sticks to itself and doesn't randomly end up in 
weird broken states (not implying that pkgsrc has this problem, but I've 
had to install other package managers that do).

> How isn't this just a pointy finger in the eye of anyone
> operating using packages from pkgsrc, with audit-packages and all
> that goes along with e.g. "pkgin fug"?

   Personally, I don't think so.  I'm not arguing that the current rust 
support in pkgsrc should be removed or changed in any way, I would 
simply like pkgsrc to be able to use already installed rust of one has 
it.  (Noting that supporting native tools is not something foreign and 
exotic to pkgsrc).

   The origin of this spelled out in a much earlier mail:  On my macs I 
build my packages on a fixed size ramdrive (to avoid wear and tear on my 
SSDs) -- unfortunately this causes any package that pulls in rust to 
fail due to the ram drive becoming full.  But it's not just that; I want 
to shorten down build times as well, and I don't want conflicting 
rustc's in my path.

   Plus, pkgsrc doesn't (afaik) run on Windows.  rustup, having a much 
smaller scope, can do things like Windows support [without its 
maintainers losing their will to live] -- and it's nice to be able to 
use the same tool, on all platforms we need, to keep our rust toolchains 
up-to-date.

>  Doesn't this just make
> the given version available for the current user?

   Yes.  This is unfortunately a side-effect of rustup being installed 
per-user.

   But truth be told, our office has almost exclusively personal 
machines; multi-user installations aren't really a thing -- it didn't 
even occur to me that this is an issue until you brought it up.  Even 
so, on some systems I install pkgsrc per-user so pkgsrc wouldn't solve 
that particular problem, had it been an issue.

   Though I will reiterate that running `rustup install 1.67.0` (or 
whatever version) is really easy for any user who already has rustup 
installed.

>  And isn't this just a path to a situation similar to
>
>    https://xkcd.com/1987/

   I guess it depends on your perspective.  From my perspective the 
issue is that pkgsrc is insisting on installing something I already 
have.  From the perspective of someone who doesn't have rust already 
installed, it's nice to have pkgsrc build everything it needs to build 
packages, without needing rustup as well.

   I think we can cater to both situations.

--
Kind Regards,
Jan