Re: Stratification of GNU Guix into Independent Channels

[Vagrant Cascadian]

On 2022-12-24, jgart wrote:
> I wanted to ask you what are your thoughts on this idea. This is a
> thought experiment at this stage.
>
> Should GNU Guix be a small core of packages (and services?)?
>
> For example, GNU Guix would be a core channel containing the reduced
> binary seed bootstrap and a few other core packages to bootstrap the
> system. That's it. Users subscribe to this channel to get started.

I definitely am excited and hopeful to think this *could* be possible!


> 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
...
> scheme-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 pros would be only having to pull the small bits you actually want,
and that could be faster to run "guix pull".

This would certainly make it much easier to package a "core" subset of
guix for other distros (e.g. I work on packaging guix in Debian) that
having to package the whole entire guix universe.

I suspect the "small bootstrap core set" to eventually pull in quite a
bit of other things, and continually be at risk of needing to pull in
more things...

You would probably need to have inter-channel dependencies... which
makes me wonder how many cyclic dependencies might result...

git alone pulls in dependencies for perl, python, git, subversion,
openssl ... and what is the dependency cycle for each of those? Guix
apparently can generate pretty charts for this stuff, though I have yet
to try. :)

I have the (perhaps mininformed) impression nix has a split more along
these lines with the core of nix being one thing, and then collections
of packages being other repositories.


> GNU Guix proper would be a solid core of packages that is very easy to
> maintain. This would greatly reduce the maintenance burden since
> maintaining a world of rust, golang, or python packages is opt in by
> those who want to do that particular work.

If it is possible, it seems likely to make releasing more regularly and
less stressfully...


> Would being subscribed to just the hypothetical small core channel in
> this proposal increase download/installation speeds given the
> availability of substitutes?

I suspect it would significantly increase guix pull speeds, at the very
least.


live well,
  vagrant

signature.asc
Description: PGP signature