proper way to resolve dependency version conflicts of rust crates?

proper way to resolve dependency version conflicts of rust crates?

[Wilko Meyer]

Hi Guix,

What's the right way to resolve version dependency conflicts for rust
crates that (in semver notation) depend on the same dependency
MAJOR.MINOR version but want a different PATCH version (e.g. 0.13.1 and
0.13.2)?

As far as I'm aware for rust crates we keep:

- all 0.MINOR versions, e.g. rust-foo-0.1,rust-foo-0.42 etc.
- as soon as a crate hits v1 we keep one package per major version >1
- (e.g. rust-foo-1, rust-foo-2).

So building packages that depend on a different PATCH-Version may under
some circumstances fail with a error similar to:

#+BEGIN_SRC
error: failed to select a version for the requirement `hashbrown = "=0.13.1"`
candidate versions found which didn't match: 0.14.3, 0.13.2, 0.12.3, ...
...
perhaps a crate was updated and forgotten to be re-vendored?
#+END_SRC

Right now I see three possible solutions to this:

1. Sent a patch to the upstream of the crate as well as to guix updating
  all crate dependencies to most-recent.
2. Define a package variant of said dependency, let's say foo-0.13-1 for
  v0.13.1 of foo.
3. Substitute the required version in Cargo.toml of a affected crate to
  match the package-version of said dependency we've packaged in Guix.

If I had to guess 3. would be the most appropriate way forward on this?

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu

Re: proper way to resolve dependency version conflicts of rust crates?

[Ignas Lapėnas]

Hi,

> 1. Sent a patch to the upstream of the crate as well as to guix updating
>   all crate dependencies to most-recent.
Sending a patch upstream updating package versions is probably desired by the
guix rust-team, can’t actually answer that. Contributing is another beast to
tackle for me some time in the future. Best guess, guix-devel mailing list
should provide an answer for that.

> 2. Define a package variant of said dependency, let’s say foo-0.13-1 for
>   v0.13.1 of foo.
I doubt that this is necessary if the package in question follows semver rules.

> 3. Substitute the required version in Cargo.toml of a affected crate to
>   match the package-version of said dependency we’ve packaged in Guix.
>
> If I had to guess 3. would be the most appropriate way forward on this?
I would go with option 3.

Currently most packages I see drops the ’=’ altogether in favor of ’^’.
For example the rust-base64 package:

┌────
│ (define-public rust-base64-0.13
│   (package
│     (inherit rust-base64-0.21)
│     (name "rust-base64")
│     (version "0.13.1")
│     (source
│      (origin
│        (method url-fetch)
│        (uri (crate-uri "base64" version))
│        (file-name
│         (string-append name "-" version ".tar.gz"))
│        (sha256
│         (base32 "1s494mqmzjb766fy1kqlccgfg2sdcjb6hzbvzqv2jw65fdi5h6wy"))
│        (modules '((guix build utils)))
│        (snippet
│         '(begin (substitute* "Cargo.toml"
│                   (("=0\\.3\\.2") "^0.3.2"))))))
│     (arguments
│      `(#:cargo-development-inputs
│        (("rust-criterion" ,rust-criterion-0.3)
│         ("rust-rand" ,rust-rand-0.6)
│         ("rust-structopt" ,rust-structopt-0.3))))))
└────

Hope my blabering helps you mate.

– 
Best Regards,
Ignas Lapėnas

Re: proper way to resolve dependency version conflicts of rust crates?

[Wilko Meyer]

Hi Ignas,

Ignas Lapėnas <ignas@lapenas.dev> writes:

> I would go with option 3.
> Hope my blabering helps you mate.

Thanks a lot! I went with option 3 in the end after having read a few
other, already present, package definition that solved this that way!

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu