guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stratification of GNU Guix into Independent Channels


From: zimoun
Subject: Re: Stratification of GNU Guix into Independent Channels
Date: Tue, 03 Jan 2023 14:26:57 +0100

Hi,

On Sat, 24 Dec 2022 at 03:49, "jgart" <jgart@dismail.de> wrote:

> Users could then decide what channels they'd like to subscribe to/opt
> in to by adding any of the following channels as they please: 
>
> python-channel
> rust-channel
[...]
> etc...
>
> The above channels would still be maintained under the auspices of
> GNU. 
>
> What do you think would be the pros and cons of the stratified
> approach versus the monorepo approach that we currently have?

The Big cons is about maintenance.

It is possible to have a look at the complete current state [1] but it
would be hard, if not impossible, when using many many many channels.
When using other channels [2], time to time it breaks.  Somehow, you
have a combinatorial problem.

Consider that some Git tools are part of one channel and for instance
Julia packages are part of another channel.  The update of Git from its
channel could have an impact on the packages defined in some other
channels; for concrete case: Git update from 2.38.0 to 2.38.1 breaks
julia-documenter [3].  Using few channels, it makes doable to tackle
such issues (guix refresh, guix graph, etc.).  Using many many channels,
it makes it hard to detect; although CI and QA are improving a lot and
for sure they can help, the situation is not good enough yet, IMHO.

Moreover, many channels would be dependant from one to the other.  Give
a look at (gnu packages python-xyz).  If the packages defined here would
become the channel ’python-channel’ then this ’python-channel’ would
depend on many others – this (gnu packages python-xyz) module requires
103 other (gnu packages …) modules.

Concretely, the split would be a painful, boring and tedious work where
I am doubtful about the practical outcome.

>From my point of view, solutions for improving the situation of “guix
pull” are:

 + more modular; maybe split *package-modules* in (guix self)
 
 + transform subcommands as extensions; here we would have a better
   control for the Guix feature dependencies via the Scheme API


1: <http://ci.guix.gnu.org/eval/78350/dashboard>
2: <https://hpc.guix.info/channels/>
3: <https://yhetil.org/guix/20221205153710.10684-1-zimon.toutoune@gmail.com>

Cheers,
simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]