Re: rust-team branch merged

[Efraim Flashner]

On Thu, Mar 07, 2024 at 11:48:53AM -0500, Jason Conroy wrote:
> On Thu, Mar 7, 2024 at 3:08 AM Efraim Flashner <efraim@flashner.co.il>
> 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 = "<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.
> 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   <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

signature.asc
Description: PGP signature