Why is only rust-1.60 exported when 1.65 is defined?

  • Done
  • quality assurance status badge
Details
7 participants
  • Greg Hogan
  • Jonas Møller
  • Matthew James Kraai
  • Maxim Cournoyer
  • (
  • ROCKTAKEY
  • Simon Tournier
Owner
unassigned
Submitted by
Jonas Møller
Severity
wishlist
J
J
Jonas Møller wrote on 8 Mar 2023 17:09
(address . bug-guix@gnu.org)
0f93d56a-f744-b7c6-2be6-2dcf7fe08741@moesys.no
Hi Guix! The rust.scm file says

Toggle quote (8 lines)
> ;;; 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
Attachment: file
M
M
Matthew James Kraai wrote on 12 Mar 2023 15:14
(address . 62064@debbugs.gnu.org)
ZA3eSbhOmLqXT27r@carlo
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
G
G
Greg Hogan wrote on 13 Mar 2023 14:36
Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
(name . Jonas Møller)(address . jonas@moesys.no)(address . 62064@debbugs.gnu.org)
CA+3U0ZkA-JMgyTNn374TTLBPhBfYw76cnO1f1smScmtU17OpFA@mail.gmail.com
On Sun, Mar 12, 2023 at 8:12?AM Jonas Møller via Bug reports for GNU
Guix <bug-guix@gnu.org> wrote:
Toggle quote (18 lines)
>
> 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.


Greg
S
S
Simon Tournier wrote on 13 Mar 2023 15:32
873568lo20.fsf@gmail.com
Hi,

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

Toggle quote (14 lines)
>> ;;; 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.

Toggle snippet (5 lines)
$ guix refresh rust -l | cut -f1 -d':'
Building the following 4560 packages would ensure 6637 dependent packages are rebuilt


Toggle quote (6 lines)
> 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
J
J
Jonas Møller wrote on 13 Mar 2023 21:59
66be3bb1-5adb-4e6b-f050-6159da88124e@moesys.no
Toggle quote (4 lines)
> 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.


— Mvh Jonas Møller
Attachment: file
(
CR5KC0A0DKM7.2RF34MV6GTLZI@guix-framework
Hi,

On Wed Mar 8, 2023 at 4:09 PM GMT, Jonas Møller via Bug reports for GNU Guix wrote:
Toggle quote (2 lines)
> 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
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...

-- (
-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEE6Vh10NblKE5doNlW7ImHg/nqI20FAmQPkX8ACgkQ7ImHg/nq
I224rgwAwGPDhgTGv2gnS+nBWbVfhbrHpiRsV3sSQyrlRVtAJoS/EkSFCVBiRndt
E8nVXE8NdTf2uGjwnjqD+gS75n1tlOIUvLAAPswn3EDKRxLcvbvSZHCJYNRAvna6
5PZm8YcOqTH9QSpMkQhzJLvR1yef1cpheIVr7tfFtb0+a6U9OdASDM2yro6TCq6z
ey5L1yFzggVQFEbBvDJgG1Rn01XP+SGTV+o3YAee3F/i91HZtZoT5B9dlxK56gAT
OHiZ258xyHcy7WuMC68jgHm6GfhDpRWpT1ANJrq7GwWy58alWcXnR6fOcZBhWUoS
yvawlIK9vyxhxTf2ljxFaWcywTCUOxs1H3QzlZwVYV7xoBijmY/faBrshqjYhVX9
6F4Busvy4EYKLjE362juQsjjlUdXIxE9nMRxFZffQE8i0ins3lMUWXi4Gyz+AU64
/z0YLa/1n6/5ClQRwrgcXXl9nPIaJsOfDrAaPNnSzC+pXcOslHQ2HDs5xwnt74rL
+6T7nKoq
=6Woz
-----END PGP SIGNATURE-----


S
S
Simon Tournier wrote on 14 Mar 2023 09:32
864jqn91hw.fsf@gmail.com
Hi Jonas,

On Mon, 13 Mar 2023 at 20:59, Jonas Møller via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:
Toggle quote (12 lines)
>> 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.


Toggle quote (4 lines)
> 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?


Cheers,
simon
J
J
Jonas Møller wrote on 14 Mar 2023 09:59
587407cb-5045-2c86-cf9b-6d331c8bc1b3@moesys.no
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
Attachment: file
R
R
ROCKTAKEY wrote on 24 Mar 2023 16:41
Why is only rust-1.60 exported when 1.65 is defined?
(address . 62064@debbugs.gnu.org)
a9e535e1-501d-2c35-f2a6-8a3156084734@gmail.com
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
S
S
Simon Tournier wrote on 3 Apr 2023 16:03
87wn2tf4gy.fsf@gmail.com
Hi,

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

Toggle quote (4 lines)
> 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.


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

Cheers,
simon
S
S
Simon Tournier wrote on 4 Apr 2023 11:30
86ilecvvsi.fsf@gmail.com
Hi,

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

Toggle quote (4 lines)
> 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?


Cheers,
simon
Z
Z
zimoun wrote on 4 Apr 2023 11:31
control message for bug #62064
(address . control@debbugs.gnu.org)
86h6twvvs1.fsf@gmail.com
severity 62064 wishlist
quit
J
J
Jonas Møller wrote on 4 Apr 2023 13:53
Re: bug#62064: Why is only rust-1.60 exported when 1.65 is defined?
TKJlgTQi1msg3FvFQ1QLOfkYMrKhELY_Ta85j2dcVG8x_h7st9R5x3Gi1hLdIcnJsnscLuUqoJPlyxP_rt8dAXEojD6Hdi6W5q7VF6bKDV4=@moesys.no
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@gmail.com> wrote:

Toggle quote (25 lines)
> Hi,
>
> On mar., 14 mars 2023 at 08:59, Jonas Møller via Bug reports for GNU Guix <bug-guix@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
Attachment: file
M
M
Maxim Cournoyer wrote on 22 Jan 06:02 +0100
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
87edea3qqm.fsf@gmail.com
tags 62064 + notabug
quit

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

Toggle quote (15 lines)
> Hi,
>
> On Mon, 13 Mar 2023 at 21:11, paren--- via Bug reports for GNU Guix <bug-guix@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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 62064@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 62064
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch