Re: guix is the guildhall that we always wanted!

[Andy Wingo]

On Fri 17 Mar 2017 10:01, Florian Paul Schmidt <address@hidden> writes:

> On 03/16/2017 11:24 PM, Ludovic Courtès wrote:
>> I think having repos maintained elsewhere is OKish, but it’s true that
>> it requires people who maintain those repos to follow closely what’s
>> going on in Guix proper because we’re not guaranteeing API stability.
>
> Wouldn't taking the functional/reproducibility aspect one step further
> migitate this issue? I.e. maintainers of decentralized repos just need
> to have as input the precise guix version they are using?

This is certainly possible.  Currently the Guix revision is an implicit
input to everything; a guix package "bar" may depend on "address@hidden", but
the precise built derivation of "foo" on which you depend will evolve
over time as the dependencies change (glibc for example).

Relying on a fixed Guix version fixes this, but at a cost of adding a
new dimension of maintenance complexity that is not reducible in an
automatic way at run-time.  I explain.

For complexity, in the Guix project itself we have one git repo with N
packages; right now packages for a given revision of git, packages only
depend on each other in that revision.  But if you start to build
systems that have packages depending on packages *at M specific
revisions in Git*, you no longer have N nodes in your graph, you have
N*M.  That's a serious increase in maintenance cost for the system as a
whole (if indeed you do decide to maintain it).

However when you actually instantiate a given application (process) it
is only going to depend on one libc, and one "libfoo".  (I know Rust's
cargo has some facility to import multiple versions of libraries.  It
does so by making the types that those versions work on distinct.  But
in Guile there's no easy facility here.)  So in practice you do have to
resolve the M revisions of Guix into a single revision.  How do you do
that in a system that depends on multiple libc versions?  In many ways
it is better to avoid the issue and have one system that evolves over
time.

When you are building an operating system as a collection of somewhat
independent packages that communicate over shared standard protocols and
not shared ABI, version skew is more manageable.  But when building
composite processes that need to agree on API and ABI internally, the
problem is hard.  A guildhall module needs to be able to compose with
other modules and for that reason I think specifying the Guix revision
is not the right thing.

Just my humble opinion of course :)

Andy