On Thu, Mar 07, 2024 at 11:48:53AM -0500, Jason Conroy wrote: > 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. More the first. I found that the actual build time was slightly faster using the antioxidant-build-system over the cargo-build-system but I wasn't in a position to take it up when the original author moved on to other things. > > 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`? Once you have something like that working it shouldn't be too hard to merge that into `guix shell`, assuming we go that route. > > > > 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