Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> [...]
>
>> Chris raises interesting issues.  I think it’s OK to first come up with
>> an implementation that has some limitations but works with the simple
>> use cases we have in mind.
>
> I’ve fixed this according to what we’ve discussed: when more than one of
> the user-provided or channel-required channels have the same name we
> ignore the more recent specification unless it is more specific
> (i.e. the new channel specification mentions a commit while the former
> did not).

As long as the "channel resolution mechanism" is deterministic, it's
probably OK.  But if you have two channels A which depends on C, and B
which depends on C', where C' is a different version of C, then we can
arrive in a situation where the author of A tests and provides support
for their package definitions in the absence of channel B, and the
author of B tests and provides support for their package definitions in
the absence of channel A, and a user who wants to use packages from both
A and B is stuck because one of the channel owners (the one whose
dependency we didn't pick) doesn't want to support that use case.

It sounds to me like we are taking all the channels are merging them
into a single profile, and then we access it using a single Guix
inferior.  That's why we feel like we have to chose a specific version
of C to use with both A and B.  In this way, "installing" multiple
channels into this one profile is similar to the propagation of multiple
packages into a single profile.

Consider package propagation.  If I have a piece of software X which
depends on library Z and another piece of software Y which depends on
Z', where Z' is a different version of Z, then we have a similar
problem.  If I install packages X and Y into my profile and the
libraries Z and Z' are propagated, it will cause conflicts, and we will
need to choose a single version of the library.  When we do that, there
is no guarantee that X or Y will function correctly, since the person
who developed X didn't test using Z', and the person who developed Y
didn't test using Z.

Instead, if we install install X and Y without propagating Z and Z', we
have a solution: X and Y can coexist in the same profile.  X refers to Z
in the store (via its rpath or equivalent), and Y refers to Z' in
another location in the store.  When the user runs X, it runs using the
library Z.  When the user runs Y, it runs using library Z'.  The user
has not "voided their warranty", so to speak, by using a version of the
library that the developer doesn't want to support.  If there's a
problem, the user can go to the developer for support more easily.

I think your proposed solution is basically "channel propagation".
Don't get me wrong: It's great that we can choose a specific version of
channel C deterministically!  This means users can share their
channels.scm file and reproduce the exact channel configuration easily.
However, it might be even better if we could figure out how to avoid
"propagating" the channels and introducing conflicts.  Maybe there is a
way to run one Guix inferior per channel, so that one inferior can be
responsible for packages from channel A (using C), and another inferior
can be responsible for packages from channel B (using C')?

By the way, even if we come up with a solution like this, I think it's
safe to say that the core Guix channel must be the same version always.
I can't currently see how it might make sense for two third-party
channels to depend on different versions of the Guix channel, since the
Guix channel provides not only package definitions but also the Guix
code.

I hope that makes sense.  Either way, your work is already an
improvement.  Thank you for it!

-- 
Chris