GNU bug report logs - #34820
[PATCH] gnu: rust: Update to 1.32.0

Previous Next

Full log

Message #41 received at 34820 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Brett Gilio <brettg <at> posteo.net>
Cc: 34820 <at> debbugs.gnu.org, Ivan Petkov <ivanppetkov <at> gmail.com>
Subject: Re: [bug#34820] [PATCH] gnu: rust: Update to 1.32.0
Date: Wed, 27 Mar 2019 12:02:34 +0100

[Message part 1 (text/plain, inline)]

Hi,

On Tue, 26 Mar 2019 21:58:07 -0500
Brett Gilio <brettg <at> posteo.net> wrote:

> > Not sure what challenges there may be with the rustup approach though

Without using the Guix package manager?  That depends on whether they can
install into $HOME.  If so, it's not difficult.

> > (will the prebuild binaries work well with guix?).

We had prebuilt Rust binaries before, but we had to patch them slightly
using patchelf.

From a strategic standpoint we'd like to reduce the number of bootstrap
seeds required for Guix packages, not increase them.  But I guess as
long as they are optional (not dependencies of anything else), that's
the user's choice.

> You are probably right, there are definitely going to be some liability
> issues about working with the nightly branch. But it was something I was
> interested in investigating. The more we deal with rust on Guix, the
> more I think that rustup is going to have to become a necessity if we
> want to attract more Rust developers to using Guix. Nightly is almost a
> requirement for a good few.

I think Rust is one of the few languages getting it right in this regard:
There is a "stable" setting where you can only access APIs in the runtime
and/or language that won't change.  If there are unfinished experimental
APIs they can expose them (to programs not written to require the "stable"
setting) and later on change them and tell everyone "I told you so".

As a distribution, we usually package stable versions of software, so it
does make sense that if the feature is unstable (subject to change in
incompatible ways in less than, say, 1 month) then it's not available.

Long story short, I don't use Rust for production projects because some
important things are not deemed stable yet--and I had to do too much
pointless rewriting in my life just because some other API changed.

But there should be nothing stopping a user from testing Rust some other
way (install into $HOME etc).

In order to test Rust nightly I use a Docker container and this script:

dannym <at> dayas ~/.local/bin$ cat in-rust-nightly 
#!/bin/sh

p="`realpath \".\"`"
# example: cargo build --release
if [ "$1" = "" ]
then
        set -- sh
fi

exec docker run --rm -e USER="${USER}" --user "$(id -u)":"$(id -g)" -v "$PWD":"${p}" -w "${p}" rustlang/rust:nightly "$@"

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.