The transitive dependencies getting pulled in automatically should work
automatically if we ever finish the antioxidant-build-system.
Since you bring up antioxidant, I'm kind of curious whether that stalled mainly due to shifts in contributor priorities, or due to significant technical issues.
Until then
I've been experimenting by manually listing the other crates I've needed
but in theory we could try to make `guix shell --development` pull in
the needed crates.
I was considering another option that falls somewhere in between: since I'm already building shells from manifest files, it should suffice to have a Scheme utility function that calculates the transitive dependencies for a given list of library packages. Similar logic seems to exist already in `(guix build-system cargo)` but it's not exposed publicly. As interim solutions go, what do you think about this one versus modifying `guix shell`?
I misread what you wrote as it was working. It's definitely something I
want but wasn't ready to work on yet.
> I took rust-rand as an example only because it does have some dependencies:
>
> $ cd $CARGO_PROJECT
> $ cat Cargo.toml
> [package]
> name = "test_prog"
> ...
> [dependencies]
> rand = "0.8.5"
>
> $ cargo build
> Updating crates.io index
> Downloaded cfg-if v1.0.0
> Downloaded rand_chacha v0.3.1
> Downloaded rand v0.8.5
> Downloaded ppv-lite86 v0.2.17
> Downloaded rand_core v0.6.4
> Downloaded getrandom v0.2.12
> Downloaded libc v0.2.153
> Downloaded 7 crates (932.0 KB) in 0.48s
> Compiling libc v0.2.153
> Compiling cfg-if v1.0.0
> Compiling ppv-lite86 v0.2.17
> Compiling getrandom v0.2.12
> Compiling rand_core v0.6.4
> Compiling rand_chacha v0.3.1
> Compiling rand v0.8.5
> Compiling test_prog v0.1.0 (/home/...)
>
>
> > Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then
> > you'd have both rand-0.*.crate files in the registry but only one of
> > them would be listed in share/cargo/registry/index/ra/nd/rand. I need to
> > adjust the generation of that file to combine multiple sources if they
> > exist, and sort them (I'm not sure it's necessary, but wouldn't be
> > surprised if we hit undefined behaviour if they were listed multiple
> > times or out of order).
>
>
> I'm somewhat new to rust, but it appears that outside of Guix, the
> local-only development workflow looks like this:
>
> $ cd $CARGO_PROJECT
> $ mkdir $VENDOR
> $ cargo vendor $VENDOR
>
> After downloading and unpacking all of the crates into $VENDOR, this last
> command instructs me to add the following in ~/cargo/config.toml.
> Then, after opening a new guix shell without network access, I can confirm
> that `cargo build` works fine with the vendored crates.
>
> [source.crates-io]
> replace-with = "vendored-sources"
>
> [source.vendored-sources]
> directory = "<VENDOR>"
I wanted local-registry over replace-with because IIRC replace-with
won't fall back to downloading from crates.io if there's missing crates,
while local-registry will check there first and then download any
missing crates. The use-case I was looking at for that was adding a new
dependency to a project and then not needing to re-create a shell or
package the new crates before continuing on.
I see, thanks. My preferred workflow is different but I acknowledge that use case.
The link below claims that one can update the vendor directory in a similar way by re-running `cargo vendor` after adding a dependency to Cargo.toml, but for your use case I agree that it's nicer if `cargo build` can pull to the registry automatically.
The registry as setup in the patches is actually mostly correct, minus
the multiple versions of a crate, it just needs to be fed the crates.
> Getting back to your patch set: would it make sense to emulate this vendor
> workflow instead of trying to construct a registry directly? Even assuming
> that all details of the registry structure are stable and documented, the
> layout of the vendor directory appears much simpler. And IIUC the code for
> setting up vendored libraries already exists in cargo-build-system.
>
> I also need to figure out something with a
> > config.toml to see if it's possible to generate one that could be
> > included from another one, since you can't add 'local-registry =
> > $GUIX_PROFILE/...' in a toml file.
> >
>
> You've probably researched this more than I have, but it seems that this
> use case is explicitly unsupported in the TOML language spec:
> https://github.com/toml-lang/toml/issues/397
>
> With that option off the table, I can't think of any elegant solutions.
> Maybe a wrapper for the cargo binary that pre-processes cargo.toml and then
> calls the real cargo?
Thanks, I didn't see that one. So it looks like environment variables
and INCLUDEs are off the table. An autoconf style macro that take a
config.toml.in and spits out a config.toml with the correct directory
would work, but from my understanding that's not really in line with any
bit of how cargo and the rust ecosystem works.
Another option would be to symlink
$GUIX_ENVIRONMENT/share/cargo/registry to ./local-registry and then add
the line 'local-registry = 'local-registry' in a config.toml.
--
Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted