Re: ‘guix publish’ now compresses archives

[Tomáš Čech]

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
(unchanging).

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

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

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

Right.

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

S_W

signature.asc
Description: Digital signature