Re: "guix potluck", a moveable feast

[ludo@gnu.org (Ludovic Courtès)]

Chris Marusich <cmmarusich@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Beside, related to Chris’ comment, I’m a bit concerned about versioning
>> in such a widely distributed repo.  The package graph in Guix has zero
>> degrees of liberty: every package is connected to other packages; every
>> Guix user sees the exact same graph.
>>
>> Here, we’d have to be more flexible and allow potluck.scm files to just
>> say “import guile” or “import guile@2.0”; “import guile” might provide
>> 2.0 on a machine running an older Guix, and it might give 2.2.9 on an
>> up-to-date machine.
>>
>> IOW, we’re no longer describing one specific graph, but instead
>> describing a family of graphs with some constraints.  The benefits are
>> decentralization, but the main drawback is non-reproducibility: the
>> result would depend on the user machine’s initial state.
>>
>> To work around that, I think the server should resolve package
>> specifications when the potluck.scm file is submitted, and insert each
>> package in the Guix package graph of the moment.  Does that make sense?
>> Maybe that’s what you were describing when you talk about rewriting
>> potluck.scm files so?
>
> When you say "insert each package in the Guix package graph," do you
> mean, "add the package definition to the Guix source tree"?

No no, it’s a separate source tree.  I mean add the potluck packages to
the graph as per GUIX_PACKAGE_PATH.

> What if "the potluck" maintained a pointer to the version (i.e., the
> commit) of the Guix package definitions that it uses as its "base"?
> From time to time, the potluck could update its pointer to point to a
> more recent version of Guix's package definitions.  In this way, every
> version of the potluck would precisely specify the dependencies of all
> the packages in that version of the potluck, including any transitive
> dependencies that ultimately come from the official Guix package
> definitions (as defined in the "base" version); there would be no
> surprising version drift.  I wonder if that would work?

Then there’s the problem that Mark pointed out earlier, which is that it
would force users to use a specific set of dependencies, possibly not
current, when using the potluck.

I think it’s nicer if both repos are decoupled, although that means we
have to pay attention to version issues when the potluck is referring to
packages provided by Guix.

> What if someone wants to add a package definition to the Guix source
> tree which depends on a package that is defined in the potluck?

I guess we wouldn’t allow that in the Guix repo proper.

Ludo’.