Re: ‘guix publish’ now compresses archives

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

Tomáš Čech <sleep_walker@gnu.org> writes:

> First, I'm not saying that we should do that for every archive, but I
> think that having a way how to automatically export this information
> would be great and I see it as a week point for using Guix packages as
> alternative to Snappy or Flatpak.

Agreed.  I think it’s unfortunate that there is no step in between the
purely symbolic and the purely binary method of sharing environments.

> Now, as long as Guix sources are part of equation and change during
> the time, you may need to keep more Guix versions. If there is some
> stable not-changing core, you probably could eliminate the need.

This is going to be virtually impossible.  Users can change Guix
locally.  We cannot assume an immutable core.

Guix packages are code.  Guix itself is mostly a library.

> 1] I guess I should better explain my position. In the discussion on
> social media I was explaining why it can't be used now for
> self-containing packages and what is missing. My goal now on the
> mailing list is here the discussion itself, to see whether it is
> possible and whether are people interested in that.

It *can* be used for self-contained packages.  “guix archive --export”
and “guix archive --import” is sufficient for people who come from the
world of bundling.  They can just take a binary archive that someone
else exported from their store and import it into their store.

It is not pretty and I wouldn’t do it, though, because I would always
want to be able to build the exact same binaries myself, which I cannot
do without the exact same version of Guix (this includes package
expressions).

> 2] I don't know much Guile, maybe there is nice way how to work with
> Scheme program from Scheme program. If I should implement it, I'd need
> to strictly "draw line" between package definitions and Guix itself,
> then I would need to parse package definitions files to identify which
> parts were used and ship those. Maybe you can get this information
> during evaluation by some side effect. I don't know Guile enough, really.

In Guix we don’t parse package definitions.  Package definitions are
code.  A package expression is evaluated to a Scheme value.  To compute
the Scheme value one needs all the definitions that are used therein.
And that’s the rest of Guix.  Package expressions are a part of the code
of Guix.  The code used inside of package expressions may change as we
encounter new problems that need to be addressed.  You cannot treat
package expressions as if they were apart from the rest of Guix.

If all you wanted was the names of all packages in a closure — that’s
easy to obtain with Guix.  Just recurse over the inputs.

But to get just a subset of Guix that is used in a closure is futile.
At the end all closures are rooted in bootstrap binaries, so it’s likely
you need a big chunk of all the Guix library definitions.  It’s easier
to just include a copy of Guix itself.

My point is that you cannot (currently?) do this after the fact for any
store item you may want to export.  You would have to embed the state of
the Guix world at store-add time in the store items themselves.  This
can be done by adding the current state of Guix to the store itself and
add it as an input to each store item.  This seems very heavy-handed,
though.

If we agree that we don’t need to be able to extract the Guix state for
*any* store item the problem is smaller and much easier to solve.
Preparing a reproducible binary package would then only involve
appending the current Guix state (including whatever Guix sees via
GUIX_PACKAGE_PATH) as a source archive to the exported closure.

~~ Ricardo