[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ‘guix publish’ now compresses archives

From: Tomáš Čech
Subject: Re: ‘guix publish’ now compresses archives
Date: Thu, 21 Jul 2016 22:50:20 +0200
User-agent: Mutt/1.6.1-neo (2016-06-11)

On Thu, Jul 21, 2016 at 07:53:45AM +0200, Ricardo Wurmus wrote:

Tomáš Čech <address@hidden> 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.

Actually the condition can be this weak - there won't be any false
positives, it will only make preparing reproducible builds damn hard.

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

That again supports the point that the code closure could gather
package code only when the library will be stable and feature complete

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.

OK, you are right.

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

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.

I'm aware of this. I'm not sure how lazy is evaluation in Guile but
interpreter knows every pieces of this information during the

If the interpreter can't share this information (and there are reasons
why not extend the language allowing querying the interpreter state
during the execution), it would need to be done with parser, that was
what I meant before (and yes, that wouldn't be elegant at all).

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.

I think I have to just accept that.

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.

That is apparently not enough.

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.

Right. And in the end it is not that bad solution either (until you
need to use two versions of Guix at the same time).

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,


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.

Yes, that sounds sufficiently complete and corresponds to intention -
not do that automatically, not to do that for all stores, but be able
to export information that when requested.

I'm afraid that in that case we'll never be able to easily combine two
or more exported closures together.

Thank you for your patience and input into this discussion.

Best regards,


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]