Vagrant Cascadian <vagr...@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