all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: Brett Gilio <brettg@posteo.net>
Cc: 34820@debbugs.gnu.org
Subject: [bug#34820] [PATCH] gnu: rust: Update to 1.32.0
Date: Wed, 27 Mar 2019 12:02:34 +0100	[thread overview]
Message-ID: <20190327120234.355cc324@scratchpost.org> (raw)
In-Reply-To: <87bm1x6n28.fsf@posteo.net>

[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

Hi,

On Tue, 26 Mar 2019 21:58:07 -0500
Brett Gilio <brettg@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@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 "$@"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-03-27 11:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12  2:21 [bug#34820] [PATCH] gnu: rust: Update to 1.32.0 Ivan Petkov
2019-03-18  3:07 ` Ivan Petkov
2019-03-19  1:47   ` Danny Milosavljevic
2019-03-22 15:33     ` Ivan Petkov
2019-03-26 13:21       ` Danny Milosavljevic
2019-03-26 14:13         ` Danny Milosavljevic
2019-03-26 15:00         ` Ivan Petkov
2019-03-26 18:14           ` Danny Milosavljevic
2019-03-26 19:18             ` Ivan Petkov
2019-03-27  1:51               ` Brett Gilio
2019-03-27  2:19                 ` Ivan Petkov
2019-03-27  2:58                   ` Brett Gilio
2019-03-27 11:02                     ` Danny Milosavljevic [this message]
2019-03-28 23:23             ` Danny Milosavljevic
2019-03-31 19:12               ` bug#34820: " Danny Milosavljevic
2019-04-01  3:25                 ` [bug#34820] " Ivan Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190327120234.355cc324@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=34820@debbugs.gnu.org \
    --cc=brettg@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.