Re: Why does Guix duplicate dependency versions from Cargo.toml?

["(" <paren@disroot.org>]

Hi,

Sorry if I came off a bit harsh in the initial reply :)  I didn't intend
for it to read as a "ugh, how don't you understand this" sort of thing
but that's what it appeared to be looking at it later.

(Communication: It's Hard™)

Aaaaaaanyway....

Jonas Møller <jonas@moller.systems> writes:
> 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?

Okay, this will require a bit of explanation about how Guix's (and
Nix's) derivations work.

As I understand it, there are broadly two types of derivations:

  - fixed-output, used for things like <ORIGIN>
  - whatever-the-opposite-is-called, used for normal things like
    packages

The reason fixed-output derivations are called that is because their
hashes are *known before the derivation is built*, or at least their
expected hashes; so Guix will download the file/repo, and if it doesn't
match the given hash, it'll throw an error.

Now, this means there's no reproducibility issue with internet access.
If produced outputs O1 and and O2 are different, then either one or both
will fail the hash check, and thus the output will never be built.
There can never *be* a reproducibility issue because if there was one on
the server side Guix would catch a hash-mismatch before the consequences
of that irreproducibility were ever felt.

Thus, *it is safe to allow internet access in a fixed-output build*,
because reproducibility issues become null and void.  Or, at least,
that's how I understand it.  On the flip side, of course, regular build
scripts are not allowed to access anything (other than stuff we can't
seem to figure out how to block, like system time) that could affect
reproducibility.

> 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.

This is actually *extraordinarily* close to what we already do.  The
cargo-build-system, when building a library, copies its entire source
into the output directory (I know, I know... But without writing our own
Rust build system, there's no alternative.)

We use this source when building packages that depend on it; the sources
of the #:CARGO-INPUTS of a package in the process of being built are
copied into a 'guix-vendor' directory, and then we pass this flag to
Cargo which makes it treat the vendor directory like a local package
registry that takes precedence over crates.io.

Hopefully that clears things up :)

  -- (