Message ID | 20230403140011.294367-1-zimon.toutoune@gmail.com |
---|---|
State | New |
Headers | show |
Series | [bug#62643] gnu: rust-1.65: Rename package to rust-next. | expand |
Hi Simon, On Mon Apr 3, 2023 at 3:00 PM BST, Simon Tournier wrote: > * gnu/packages/rust.scm (rust-next): New exported variable, formerly known as > "rust-1.65". For the reasons I outlined in <https://issues.guix.gnu.org/62064#5>, we can't just export RUST-1.65 as RUST-NEXT, unfortunately... -- (
Hi, "(" <paren@disroot.org> writes: > Hi Simon, > > On Mon Apr 3, 2023 at 3:00 PM BST, Simon Tournier wrote: >> * gnu/packages/rust.scm (rust-next): New exported variable, formerly known as >> "rust-1.65". > > For the reasons I outlined in <https://issues.guix.gnu.org/62064#5>, we can't > just export RUST-1.65 as RUST-NEXT, unfortunately... Agreed. If there is a need for newer public rust version, please go through the maintainers' note above the 'rust' variable: ;;; 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. Usually the whole collection keeps building with the latest rust version as it's backward compatible, I think, so it's not as much work as it may look like. OK to close?
On Monday, 3 April 2023 23:05:24 IDT Maxim Cournoyer wrote: > Hi, > > "(" <paren@disroot.org> writes: > > Hi Simon, > > > > On Mon Apr 3, 2023 at 3:00 PM BST, Simon Tournier wrote: > >> * gnu/packages/rust.scm (rust-next): New exported variable, formerly > >> known as "rust-1.65". > > > > For the reasons I outlined in <https://issues.guix.gnu.org/62064#5>, we > > can't just export RUST-1.65 as RUST-NEXT, unfortunately... > > Agreed. If there is a need for newer public rust version, please go > through the maintainers' note above the 'rust' variable: > > ;;; 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. > > Usually the whole collection keeps building with the latest rust version > as it's backward compatible, I think, so it's not as much work as it may > look like. > > OK to close? I'd rather work on upgrading the whole rust ecosystem packaged in Guix than keep a newer version of rust working while fielding questions about why it's not yet the default.
Hi, On Mon, 03 Apr 2023 at 16:05, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: >>> * gnu/packages/rust.scm (rust-next): New exported variable, formerly known as >>> "rust-1.65". >> >> For the reasons I outlined in <https://issues.guix.gnu.org/62064#5>, we can't >> just export RUST-1.65 as RUST-NEXT, unfortunately... I understand that the current rust-1.65 is unusable by itself because it misses some part as explained by <https://issues.guix.gnu.org/62064#5>. However, I do not understand that… > Agreed. If there is a need for newer public rust version, please go > through the maintainers' note above the 'rust' variable: > > ;;; Note: Only the latest versions of Rust are supported and tested. How 1.60 could be the latest compared to 1.65? Said differently, why 1.65 is packaged if it is unusable? Even, what is the point to maintain 1.61, 1.62, 1.63, 1.64 and 1.65 if they are unexported and unusable? These 5 versions are not part of the bootstrap of 1.60. If the work for updating the Rust ecosystem is a work in progress and this work is currently in the middle, why is it not done in a dedicated branch? Cheers, simon
Hi,
On Mon, 03 Apr 2023 at 16:05, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> OK to close?
Yes. :-)
Although the confusion pointed by #62064 [1] is not fixed.
1: https://issues.guix.gnu.org/issue/62064
Cheers,
simon
Hi Simon, Simon Tournier <zimon.toutoune@gmail.com> writes: > Hi, > > On Mon, 03 Apr 2023 at 16:05, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > >>>> * gnu/packages/rust.scm (rust-next): New exported variable, formerly known as >>>> "rust-1.65". >>> >>> For the reasons I outlined in <https://issues.guix.gnu.org/62064#5>, we can't >>> just export RUST-1.65 as RUST-NEXT, unfortunately... > > I understand that the current rust-1.65 is unusable by itself because it > misses some part as explained by <https://issues.guix.gnu.org/62064#5>. > > However, I do not understand that… > >> Agreed. If there is a need for newer public rust version, please go >> through the maintainers' note above the 'rust' variable: >> >> ;;; Note: Only the latest versions of Rust are supported and tested. > > How 1.60 could be the latest compared to 1.65? Perhaps it was an oversight, or preparation for the next bump? (getting to know the hash and any new inputs needed, etc., without doing the actual work of migrating the leaf rust definition to the latest rust). > Said differently, why 1.65 is packaged if it is unusable? Even, what is > the point to maintain 1.61, 1.62, 1.63, 1.64 and 1.65 if they are > unexported and unusable? These 5 versions are not part of the bootstrap > of 1.60. See above justification. It's an internal package. You won't find it at the CLI, so you can't really say that "it's packaged" :-). > If the work for updating the Rust ecosystem is a work in progress and > this work is currently in the middle, why is it not done in a dedicated > branch? With the new teams flow, I hope that can be used for that way too. I'd prefer always having the leaf rust package exported and no newer trailing but not there yet variants. I think we all agree. We just need a champion to do it :-).
Hello, Simon Tournier <zimon.toutoune@gmail.com> writes: > Hi, > > On Mon, 03 Apr 2023 at 16:05, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: > >> OK to close? > > Yes. :-) > > Although the confusion pointed by #62064 [1] is not fixed. > > 1: https://issues.guix.gnu.org/issue/62064 That is a question more than a problem (the real problem being that our rust is old -- 1.60), which I think we have already discussed and agreed is sub-optimal and probably stemmed from a misunderstanding :-).
Hi Maxim, On Mon, 03 Apr 2023 at 23:53, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote: >> 1: https://issues.guix.gnu.org/issue/62064 > > That is a question more than a problem (the real problem being that our > rust is old -- 1.60), which I think we have already discussed and agreed > is sub-optimal and probably stemmed from a misunderstanding :-). I am closing this one and I will close the other one since the work is clear: champion the Rust ecosystem upgrade. :-) Cheers, simon
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm index 133c46fb7c..f39a7faac9 100644 --- a/gnu/packages/rust.scm +++ b/gnu/packages/rust.scm @@ -641,12 +641,16 @@ (define rust-1.64 (string-append name "\"" ,%cargo-reference-hash "\""))) (generate-all-checksums "vendor")))))))))) -(define rust-1.65 +;;; Note: Updating Rust is a core-updates change and so the package defined as +;;; 'rust' cannot always be the latest version. This package 'rust-next' is +;;; the latest version of Rust. +(define-public rust-next (let ((base-rust (rust-bootstrapped-package rust-1.64 "1.65.0" "0f005kc0vl7qyy298f443i78ibz71hmmh820726bzskpyrkvna2q"))) (package (inherit base-rust) + (name "rust-next") (source (origin (inherit (package-source base-rust))