bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Jonas Møller via Bug reports for GNU Guix]

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

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

[-- Attachment #2: Type: text/html, Size: 1598 bytes --]

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Matthew James Kraai]

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

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Greg Hogan]

On Sun, Mar 12, 2023 at 8:12 AM Jonas Møller via Bug reports for GNU
Guix <bug-guix@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

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Simon Tournier]

Hi,

On mer., 08 mars 2023 at 16:09, Jonas Møller via Bug reports for GNU Guix <bug-guix@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

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Jonas Møller via Bug reports for GNU Guix]

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

> 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

[-- Attachment #2: Type: text/html, Size: 2087 bytes --]

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Simon Tournier]

Hi Jonas,

On Mon, 13 Mar 2023 at 20:59, Jonas Møller via Bug reports for GNU Guix <bug-guix@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

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Jonas Møller via Bug reports for GNU Guix]

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

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 #2: Type: text/html, Size: 798 bytes --]

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Simon Tournier]

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

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Jonas Møller via Bug reports for GNU Guix]

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

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:

> 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 #2: Type: text/html, Size: 1855 bytes --]

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[paren--- via Bug reports for GNU Guix]

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

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...

    -- (

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Simon Tournier]

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?

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

Cheers,
simon

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[Maxim Cournoyer]

tags 62064 + notabug
quit

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

> 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

bug#62064: Why is only rust-1.60 exported when 1.65 is defined?

[ROCKTAKEY]

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