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

[Greg Hogan <code@greghogan.com>]

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