Hello there,

On 2022-03-31 17:40, Maxime Devos wrote:

>> > Instead of defining a new package, WDYT renaming 'rust-minimal-
>> lexical-
>> > 0.1' to 'rust-minimal-lexical' and updating it to 0.2?  If so,
>> you'll
>> > have to check if rust-nom@7 still builds.
>> 
>> semver is very strongly followed in the rust community, so 0.1 isn't
>> necessarily compatible with 0.2. That's how we've ended up with the
>> numerical suffix on all the rust packages.
>
> It isn't 100% theoretically compatible.  However, it might be
> _sufficiently_ compatible for all packages using rust-minimal-lexical 
> in Guix.  The same seems to hold often for non-Rust packages, I don't
> see a reason to make an exception for Rust.  Why do we package separate
> 0.Y versions (or separate major versions, for that matter) for Rust
> packages and not for, say, Guile, Python and C packages?

nom-7.0 is not forward compatible with nom-7.1. I need 7.1 for future contributions and this is why I added it into patchset. In developer's manifest of nom-7.1 dependency on rust-minimal-lexical has been updated from 0.1 to 0.2. For both versions dependencies on exact versions on rust-minimal-lexical are pinned by crate developers and we cannot change it at will. Multiple packages depends on rust-nom-7. At least on of them, rust-rusticata-macros, requires nom 7.0 exactly. Thus, we need rust-nom-7.1 as a separate package.
g
It looks like the standard here in Guix:

$ grep -P 'define-public [^ ]+-\d+[.]\d+$' gnu/packages/crates-io.scm | wc -l
2320 Rust packages in form PACKAGENAME-X.Y

$ grep -P 'define-public [^ ]+-\d+$' gnu/packages/crates-io.scm | wc -l
536 Rust packages in form PACKAGENAME-X

$ grep -P 'define-public [^ ]+\D$' gnu/packages/crates-io.scm|wc -l
3 Rust packages in form PACKAGENAME


Thank you for review! I am newbie Guix contributor.


--