Pjotr, On 24/07/2016 5:30, Pjotr Prins wrote: > After some thought I am coming to the following: my primary goals are > to lower the barrier to entry, scale out development of Guix packages > and have people collaborate on each others packages without some > centralized 'opinion'.
I've also been thinking about this a lot, which I hope will become a less frustrating affair the more I become familiar with Guix internals. > The main problems with the current GUIX_PACKAGE_PATH approach are > [...]you need a Guix source tree[...] Oh. Really? That seems like something that shouldn't be. > My immediate idea was to have a separate project, i.e. a fast and lossy > tree next to the current 'strict' tree. With a distribution server > 'guix publish' that could work for those who are inclined to use a > lossy server (call it experimental or agile package definitions). > > After some thought I decided there is still a major downside - it will > depend on central people to manage this second tree - even if it is > only for merging packages and git trees. That competes with the main > effort too which is inefficient. > > Now I think we may better solve this with something akin to a plugin > system that we have with Rubygems, Python pip etc. A plugin system > that is truly distributed from source (you just need to provide a > registry). One example I worked on before is http://biogems.info/ for > Ruby packages in bioinformatics. I have no experience with those languages. What do you see a ‘registry’ for Guix being, exactly? A long time ago — at least it seems like it[1] — I did run Exherbo, a source-based distribution based in part on Gentoo. Unlike Gentoo, it had no concept of a centralised package repository. Instead, there were a few repositories maintained by core developers (something akin to ‘core’, ‘net’, ‘x11’...) and some others maintained by random developers/userst (‘alice’, ‘bob’, ...). It didn't really matter, though: they were distributed and managed in the same way. It reminds me of Guix's (gnu package ...) collections, actually. Package repositories were simply git/svn/... trees hosted wherever. The only difference between the core repository and the others was that it was configured/trusted by default. You could remove it just like any other, if you liked fixing your system. I was able to run the equivalent of, in Guix pseudocode: ~# guix package --install footools guix package: error: footools: unknown package [maybe it even suggested a list of repositories with packages named ‘footools’, I don't remember] ~# guix repository --add my-cool-repository [what is currently gnu/packages would be just another repository] ~# guix pull [fetches all repositories from their own URI, no central point] ~# guix package --install footools [footools is now installed] ~# guix package --install bar guix package: error: ‘bar’ requires ‘(input "blah")’ which isn't in any of your trusted repositories, try adding one of the following: ... It was an almost perfect system, IMO. Anyway, I'm definitely rambling. > Personally I think this will be very exciting. We can have a > metaregistry that lists all these packages so everyone can track them. Definitely count me as excited, too. :-) Though if it's a fork, I'll cry. Kind regards, T G-R [1]: Some details may be wrong. My brain has an eager garbage collector.
