On Thu, Mar 7, 2024 at 3:08 AM Efraim Flashner wrote: > 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 = "" > > 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. https://old.reddit.com/r/rust/comments/uvvmjy/how_to_include_vendored_crates_into_a_project/ > 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 רנשלפ םירפא > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted >