GNU bug report logs - #62064
Why is only rust-1.60 exported when 1.65 is defined?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62064 in the body.
You can then email your comments to 62064 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jonas Møller <jonas <at> moesys.no>
To: bug-guix <at> gnu.org
Subject: Why is only rust-1.60 exported when 1.65 is defined?
Date: Wed, 08 Mar 2023 16:09:32 +0000

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

Hi Guix! The rust.scm file says

> ;;; Note: Only the latest versions of Rust are supported and tested. The
> ;;; intermediate rusts are built for bootstrapping purposes and should not
> ;;; be relied upon. This is to ease maintenance and reduce the time
> ;;; required to build the full Rust bootstrap chain.
> ;;;
> ;;; Here we take the latest included Rust, make it public, and re-enable tests
> ;;; and extra components such as rustfmt.

And then proceeds to define-public rust as rust-1.60, and I was wondering if there's any particular reason why a year-old version is used rather than the 1.65 version. This seems like a mistake, given that the comment claims that the "latest included Rust" should be made public.

This is especially troublesome for Rust on Guix because of both how fast its ecosystem moves onto new language/tooling features, and because using rustup (the solution for this on other slow-moving distros) relies on pre-built executables that don't work out-of-the-box on Guix.

— Mvh Jonas Møller

[Message part 2 (text/html, inline)]

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

From: Matthew James Kraai <kraai <at> ftbfs.org>
To: 62064 <at> debbugs.gnu.org
Subject: Re: Why is only rust-1.60 exported when 1.65 is defined?
Date: Sun, 12 Mar 2023 07:14:33 -0700

Hi,

I believe that rust-1.60 is exported when 1.65 is defined because
changing the exported version would require rebuilding too many
dependencies.

unmatched-paren mentioned adding a rust-latest package on IRC to avoid
this issue.

-- 
Matt

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

From: Greg Hogan <code <at> greghogan.com>
To: Jonas Møller <jonas <at> moesys.no>
Cc: 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Mon, 13 Mar 2023 09:36:12 -0400

On Sun, Mar 12, 2023 at 8:12 AM Jonas Møller via Bug reports for GNU
Guix <bug-guix <at> gnu.org> wrote:
>
> Hi Guix! The rust.scm file says
>
> ;;; Note: Only the latest versions of Rust are supported and tested.  The
> ;;; intermediate rusts are built for bootstrapping purposes and should not
> ;;; be relied upon.  This is to ease maintenance and reduce the time
> ;;; required to build the full Rust bootstrap chain.
> ;;;
> ;;; Here we take the latest included Rust, make it public, and re-enable tests
> ;;; and extra components such as rustfmt.
>
> And then proceeds to define-public rust as rust-1.60, and I was wondering if there's any particular reason why a year-old version is used rather than the 1.65 version. This seems like a mistake, given that the comment claims that the "latest included Rust" should be made public.
>
> This is especially troublesome for Rust on Guix because of both how fast its ecosystem moves onto new language/tooling features, and because using rustup (the solution for this on other slow-moving distros) relies on pre-built executables that don't work out-of-the-box on Guix.
>
>
> — Mvh Jonas Møller

Hi Jonas,

Is this question in regards to the current or future status of Rust in
Guix? Historically, updating Rust has been considered a core-updates
level change due to the number of dependent packages [0]. Under the
new feature branch workflow there was a recent announcement [1] by the
Rust team that 1.67 is in testing [2].

Can Guix's build farm keep up with Rust's six week release cycle? The
compute looks to be available but I don't recall a discussion for
consideration of storage or a blueprint for pruning old packages.

[0] https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
[1] https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00002.html
[2] https://ci.guix.gnu.org/jobset/rust-team

Greg

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

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Jonas Møller <jonas <at> moesys.no>, 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Mon, 13 Mar 2023 15:32:23 +0100

Hi,

On mer., 08 mars 2023 at 16:09, Jonas Møller via Bug reports for GNU Guix <bug-guix <at> gnu.org> wrote:

>> ;;; Note: Only the latest versions of Rust are supported and tested. The
>> ;;; intermediate rusts are built for bootstrapping purposes and should not
>> ;;; be relied upon. This is to ease maintenance and reduce the time
>> ;;; required to build the full Rust bootstrap chain.
>> ;;;
>> ;;; Here we take the latest included Rust, make it public, and re-enable tests
>> ;;; and extra components such as rustfmt.
>
> And then proceeds to define-public rust as rust-1.60, and I was
> wondering if there's any particular reason why a year-old version is
> used rather than the 1.65 version. This seems like a mistake, given
> that the comment claims that the "latest included Rust" should be made
> public.

Well, I know few about Rust and I guess it is because using ’rust-1.65’
as default Rust is a world-rebuild.

--8<---------------cut here---------------start------------->8---
$ guix refresh rust -l | cut -f1 -d':'
Building the following 4560 packages would ensure 6637 dependent packages are rebuilt
--8<---------------cut here---------------end--------------->8---


> This is especially troublesome for Rust on Guix because of both how
> fast its ecosystem moves onto new language/tooling features, and
> because using rustup (the solution for this on other slow-moving
> distros) relies on pre-built executables that don't work
> out-of-the-box on Guix. 

Well, the issue when exporting ’rust-1.65’ is that it would possible
incompatible with the Rust packages provided by Guix and compiled with
’rust’ (1.60).

Maybe, one could imagine a package transformation
’package-with-explicit-rust’ as it is done for Python and OCaml.


Cheers,
simon

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

From: Jonas Møller <jonas <at> moesys.no>
To: Simon Tournier <zimon.toutoune <at> gmail.com>, 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Mon, 13 Mar 2023 20:59:09 +0000

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

> Well, the issue when exporting ’rust-1.65’ is that it would possible
> incompatible with the Rust packages provided by Guix and compiled with
> ’rust’ (1.60).

Rust has very strong stability guarantees between 1.x releases, and has a very extensive set of tooling/infrastructure to make sure no breaking changes make their way into a release (see crater [1]). Any Rust-based package big enough to be packaged by Guix will have had its test-suite confirmed to work with the new release of cargo/rustc long before any new release is made (and in many cases before pull-requests are merged.)

Nevertheless, rebuilding all Rust packages on every rustc release isn't strictly necessary. (Improvements in optimizations do happen, but they are mosty minor release-to-release.)

But I agree with your ’package-with-explicit-rust’ idea, it is very unfortunate that "Rust, the development environment used by Guix users building Rust software" and "Rust, the build environment we use to build all Guix Rust packages" got conflated in Guix.

[1]: https://github.com/rust-lang/crater

— Mvh Jonas Møller

[Message part 2 (text/html, inline)]

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

From: "(" <paren <at> disroot.org>
To: Jonas Møller <jonas <at> moesys.no>, <62064 <at> debbugs.gnu.org>
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Mon, 13 Mar 2023 21:11:26 +0000

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

Hi,

On Wed Mar 8, 2023 at 4:09 PM GMT, Jonas Møller via Bug reports for GNU Guix wrote:
> And then proceeds to define-public rust as rust-1.60, and I was wondering if there's any particular reason why a year-old version is used rather than the 1.65 version. This seems like a mistake, given that the comment claims that the "latest included Rust" should be made public.

There's another important reason:

  rust != rust-1.60

The packages are not one and the same, despite the former being derived from the
latter.  The RUST-1.X packages are not full Rust packages; they are cut down
intentionally (no tests, no non-essential tools) to reduce bootstrapping time,
which means we need to essentially revert those changes in the public RUST package
to get something that we can actually expose to users.

That's why the RUST variable isn't defined like this:

  (define-public rust rust-1.60)

It's defined like this:

  (define-public rust
    (package
      (inherit rust-1.60)
      ;; --8<-- a VERY extensive set of overrides to readd removed stuff --8<--
      …))

So to add a RUST-LATEST, we'd need to have another one of these monstrosities
(seriously, it's evil <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/rust.scm#n663>)
but because it's mostly source code patches, we couldn't just make some kind of
MAKE-PUBLIC-RUST procedure, as a SUBSTITUTE* that works for 1.60 may not work
for 1.65...

    -- (

[signature.asc (application/pgp-signature, inline)]

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

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Jonas Møller <jonas <at> moesys.no>, 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Tue, 14 Mar 2023 09:32:43 +0100

Hi Jonas,

On Mon, 13 Mar 2023 at 20:59, Jonas Møller via Bug reports for GNU Guix <bug-guix <at> gnu.org> wrote:
>> Well, the issue when exporting ’rust-1.65’ is that it would possible
>> incompatible with the Rust packages provided by Guix and compiled with
>> ’rust’ (1.60).
>
> Rust has very strong stability guarantees between 1.x releases, and
> has a very extensive set of tooling/infrastructure to make sure no
> breaking changes make their way into a release (see crater [1]). Any
> Rust-based package big enough to be packaged by Guix will have had its
> test-suite confirmed to work with the new release of cargo/rustc long
> before any new release is made (and in many cases before pull-requests
> are merged.)

To test your claim, I would suggest to write a manifest using package
transformations [1] and then rebuild all Rust packages from Guix.

1: https://guix.gnu.org/manual/devel/en/guix.html#Package-Transformation-Options
2: https://guix.gnu.org/manual/devel/en/guix.html#Defining-Package-Variants

> Nevertheless, rebuilding all Rust packages on every rustc release
> isn't strictly necessary. (Improvements in optimizations do happen,
> but they are mosty minor release-to-release.)

I do not understand how this could be implemented with Guix.  Could you
be more specific?


Well, all in all, I do not think this report is a bug but a wish list.
Instead, I would suggest to discuss the actionable tasks for updating
Rust [3] in the mailing list guix-devel, WDYT?

3: https://guix.gnu.org/manual/devel/en/guix.html#Defining-Package-Variants

Cheers,
simon

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

From: Jonas Møller <jonas <at> moesys.no>
To: Simon Tournier <zimon.toutoune <at> gmail.com>, 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Tue, 14 Mar 2023 08:59:09 +0000

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

I think it's fine for Guix to use a specific version of Rust internally, and to be conservative about updating that.

But Guix becomes unsuitable for anyone developing software in Rust, if this technical detail in the package manager means that they can't use newer versions of the toolchain.

I think it would be best if Guix separated these concerns, by disconnecting the "Rust we use to build packages internally" with the "Rust that gets installed with `guix install rust`"

— Mvh Jonas Møller

[Message part 2 (text/html, inline)]

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

From: ROCKTAKEY <rocktakey <at> gmail.com>
To: 62064 <at> debbugs.gnu.org
Subject: Why is only rust-1.60 exported when 1.65 is defined?
Date: Sat, 25 Mar 2023 00:41:31 +0900

Hi,

Some of cargo packages require rust-1.61 or higher. Currently, there is 
no way to build them with Guix because of this issue.

So I think cargo-build-system (and other build-systems?) should be able 
to specify the version of rust. As of now, it accepts #:rust keyword, 
but there is no package to pass it to (because the packages named 
rust-1.* are not public).

Providing newer Rust packages are needed in this regard as well.

ROCKTAKEY

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

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Jonas Møller <jonas <at> moesys.no>, 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Mon, 03 Apr 2023 16:03:09 +0200

Hi,

On mar., 14 mars 2023 at 08:59, Jonas Møller via Bug reports for GNU Guix <bug-guix <at> gnu.org> wrote:

> I think it would be best if Guix separated these concerns, by
> disconnecting the "Rust we use to build packages internally" with the
> "Rust that gets installed with `guix install rust`" 

Using your proposal, how do you deal with

    guix install rust rust-foobar

?  Do you expect that rust-foobar is built using the latest Rust or the
internal Rust?

Well, from my point of view, what you would like is that the symbol
’rust-1.65’ would be named “rust-next”.  It is the current way for
several versions; see emacs vs emacs-next.

See https://issues.guix.gnu.org/62643

I propose to close this report once #62643 is merged.

Cheers,
simon

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

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: "(" <paren <at> disroot.org>, Jonas Møller <jonas <at> moesys.no>,
 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Tue, 04 Apr 2023 11:30:53 +0200

Hi,

On Mon, 13 Mar 2023 at 21:11, paren--- via Bug reports for GNU Guix <bug-guix <at> gnu.org> wrote:

> There's another important reason:
>
>   rust != rust-1.60

Well, as discussed in [1]

    [bug#62643] [PATCH] gnu: rust-1.65: Rename package to rust-next.

this report #62064 is not a bug but instead a wish list: upgrade the
Rust ecosystem.  Therefore, I am in favor to close it.  WDYT?

1: http://issues.guix.gnu.org/issue/62643

Cheers,
simon

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

From: Jonas Møller <jonas <at> moesys.no>
To: zimon.toutoune <at> gmail.com, 62064 <at> debbugs.gnu.org
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Tue, 04 Apr 2023 11:53:18 +0000

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

Yes, rust-next works, but I was imagining renaming the current rust to something like default-rust-build, then defining a new ‘rust’ which will be continuously updated to the latest version of rust.

I think a user centric design would name the latest rust as just ‘rust’, while letting the package-manager implementation detail have the longer name.

Mvh Jonas Møller

On Mon, Apr 3, 2023 at 16:03, Simon Tournier <zimon.toutoune <at> gmail.com> wrote:

> Hi,
>
> On mar., 14 mars 2023 at 08:59, Jonas Møller via Bug reports for GNU Guix <bug-guix <at> gnu.org> wrote:
>
>> I think it would be best if Guix separated these concerns, by
>> disconnecting the "Rust we use to build packages internally" with the
>> "Rust that gets installed with `guix install rust`"
>
> Using your proposal, how do you deal with
>
> guix install rust rust-foobar
>
> ? Do you expect that rust-foobar is built using the latest Rust or the
> internal Rust?
>
> Well, from my point of view, what you would like is that the symbol
> ’rust-1.65’ would be named “rust-next”. It is the current way for
> several versions; see emacs vs emacs-next.
>
> See https://issues.guix.gnu.org/62643
>
> I propose to close this report once #62643 is merged.
>
> Cheers,
> simon

[Message part 2 (text/html, inline)]

Message #45 received at 62064-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: "\(" <paren <at> disroot.org>, 62064-done <at> debbugs.gnu.org,
 Jonas Møller <jonas <at> moesys.no>
Subject: Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
Date: Mon, 22 Jan 2024 00:02:25 -0500

tags 62064 + notabug
quit

Simon Tournier <zimon.toutoune <at> gmail.com> writes:

> Hi,
>
> On Mon, 13 Mar 2023 at 21:11, paren--- via Bug reports for GNU Guix <bug-guix <at> gnu.org> wrote:
>
>> There's another important reason:
>>
>>   rust != rust-1.60
>
> Well, as discussed in [1]
>
>     [bug#62643] [PATCH] gnu: rust-1.65: Rename package to rust-next.
>
> this report #62064 is not a bug but instead a wish list: upgrade the
> Rust ecosystem.  Therefore, I am in favor to close it.  WDYT?

Done.  We're currently at rust 1.73 on core-updates.

-- 
Thanks,
Maxim

Previous Next

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