Re: A registry for distributed sources and binaries

[Tobias Geerinckx-Rice]

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.