all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: jgart <jgart@dismail.de>, guix-devel@gnu.org
Subject: Re: Stratification of GNU Guix into Independent Channels
Date: Tue, 03 Jan 2023 14:26:57 +0100	[thread overview]
Message-ID: <86zgaz7nq6.fsf@gmail.com> (raw)
In-Reply-To: <84400bcea3eee39dc15d82812a8006bb@dismail.de>

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



  parent reply	other threads:[~2023-01-03 13:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-24  3:49 Stratification of GNU Guix into Independent Channels jgart
2022-12-24  4:31 ` Vagrant Cascadian
2022-12-24 12:31   ` Joshua Branson
2022-12-24  5:24 ` jgart
2022-12-24  8:37   ` Stratification of GNU Guix into Independent Channels, X-mas and Guix days! Pjotr Prins
2022-12-25 12:00     ` indieterminacy
2022-12-25 16:27     ` jgart
2022-12-24 11:01 ` Stratification of GNU Guix into Independent Channels Liliana Marie Prikler
2022-12-24 11:37 ` Josselin Poiret
2022-12-27 13:50 ` Hartmut Goebel
2022-12-29  1:25 ` Denis 'GNUtoo' Carikli
2023-01-03 13:26 ` zimoun [this message]
2023-01-27  7:47   ` Giovanni Biscuolo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86zgaz7nq6.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=jgart@dismail.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.