Re: Stratification of GNU Guix into Independent Channels

[Joshua Branson]

Vagrant Cascadian <vagrant@debian.org> writes:

> 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. :)
>

Fun fact of the day, the OpenBSD crowd is creating got, which is a
rewrite of git, with less features, in C.  :)

>
> 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