bug#22629: Channels!

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

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Look at the wider Linux world: there are people who want to live on
> the bleeding edge and run Arch Linux, and there are others who value
> stability and run CentOS. Today's Guix is more on the bleeding edge
> side. My understanding of your commment is that you would like to make
> sure it stays there. But that also means severely limiting Guix'
> potential user base.

Mark’s concern is not about whether packages are the latest version,
etc.  It’s about the constraints that could result from widespread
development of channels outside Guix proper: technically all of Guix is
just a library, so widespread development of external channels could
force us Guix developers to keep the API stable.  This, in turn, would
limit our ability to make significant changes to Guix.

> I see channels as an opportunity to have Guix "dialects" addressing
> different needs and yet remain interoperable, although I am the first
> to admit that I have no clear idea of how this would work out in
> practice, more from the social than the technical point of view. But
> the goal looks very attractive. Looking at my own use of Guix, I am
> happy with its bleeding edge approach for the software I use for
> research, but I'd much prefer a slower pace and more stability for
> stuff like Emacs and TeX that are "boring infrastructure" for me.

“Dialect” sounds a bit strong, but I agree that such uses could be
interesting and beneficial, to users and to Guix.

>> Even things as seemingly innocuous as moving a package from one module
>> to another will impact these third-party channels, not to mention
>> changing our internal APIs or making fundamental changes to the way
>> packages are specified.
>
> So... could we reduce the dependence of package specifications on such
> things? Package definitions use a small DSL that could be versioned,
> allowing change while maintaining compatibility. Module dependencies
> are more annoying, but do we need them? Package definitions are
> grouped into modules mostly for convenience. All packages have
> globally unique names, so could we use those to specify inputs?

This is exactly that kind of issue Mark is concerned with: currently we
don’t have to worry at all about this, and it’s great to have that
freedom.

I’d rather not build fancy mechanisms just for the sake of external
channels, and I certainly don’t want to commit to API stability.  We
won’t break the API every day intentionally either, but my point is that
support for external channels will be “best effort” (as it already is
with GUIX_PACKAGE_PATH).  I think it’s useful and practical nonetheless.

Ludo’.