Interesting, Guix already has git/url-fetch, what is keeping Guix from simply fetching a cargo project and then running `cargo build` in the fetched source directory?
If the problem is that the build daemon is sandboxed and doesn't have internet access, it is also feasible to have one stage of the build process download all the resources specified in Cargo.lock (and cache this in /gnu/store) and rewrite `version = "x.y.z"` to `path = "x/y/z"` before everything is passed to the build daemon. I just don't see why this can't be ad-hoc. ------- Original Message ------- On Thursday, August 24th, 2023 at 09:05, ( <pa...@disroot.org> wrote: > > > Jonas Møller jonas@moller.systems writes: > > > Hi Guix! Why does cargo-build-system need #:cargo-inputs specified in the > > package definition? This seems like a > > big mistake for a couple of reasons. > > > > 1 It is completely redundant, it should match what is in Cargo.toml. I know > > `guix import crate` exists to > > automate this process, but I don't understand the rationale for duplicating > > this information. > > > Because it'd be literally impossible to do otherwise. You'd have to > contort Guix into some pretty weird shapes to change a package > derivation based on what was downloaded as the source. > > -- (
