Re: A registry for distributed sources and binaries

[Andreas Enge <andreas@enge.fr>]

Hello,

On Sun, Jul 24, 2016 at 05:30:27AM +0200, Pjotr Prins wrote:
> 2. Slightly complicated (you need a Guix source tree etc.)

as far as I understand it, our "data is code" approach makes it necessary
to have the Guix tree around in any case. "guix package -i ruby" looks
up the package variable with name "ruby" in the local Guix tree, which
may be installed in ways different from using git ("guix pull" comes to mind).

On Sun, Jul 24, 2016 at 09:41:49AM +0200, Pjotr Prins wrote:
> In my mind we don't need much of an API. We need a way for plugins to
> tell what hooks they provide and then call into these hooks. That is
> all. Plugins don't get access to Guix internals per se - though we
> could run them in the same space.

So when your registry defines a package that depends on ruby, it somehow
needs to import the scheme variable of the same name, which resides in,
say, the central Guix tree. So it is not a matter of simply adding hooks.
(Of course, I suppose that external scheme files could be "added" to the
local tree as the files in GUIX_PACKAGE_PATH are, but I am not sure whether
this is what you mean).

> After some thought I am coming to the following: my primary goals are
> to lower the barrier to entry
> 1. People are not aware about the work of others
> 3. No binary distribution

One of my main concerns with your suggestion (besides the technical one) is
that I do not think it lowers the barrier to entry, but it diverts the
efforts. With package repositories full of packages around, where a half-
baked recipe can simply be dropped for the world to use, what would be the
incentive of contributing back into the main project?

My impression is that it is extraordinarily easy to contribute to Guix:
Anybody can post packages to the mailing list, and after a bit of back
and forth, they are usually added. No copyright assignment, no need to
become a "Guix maintainer". Making it even easier essentially means dropping
quality control. Then packages of bad quality floating around Guix would
mean bad publicity.

A problem, as mentioned in another reply, is the lack of people doing code
review, which is not a very rewarding task. That can be changed by everyone
of us :-)

And I think we need to work on our tooling and processes; the approach of
submitting patches to this mailing list is not set in stone. Apart from that,
I do not think that the claim of patch loss is justified: This may happen
from time to time, but not on a regular basis.

On Sun, Jul 24, 2016 at 05:30:27AM +0200, Pjotr Prins wrote:
> have people collaborate on each others packages without some
> centralized 'opinion'.
On Sun, Jul 24, 2016 at 03:48:48PM +1000, Jookia wrote:
> We're all a bit frustrated
> with each other at the moment because we have different goals.
> There could be a guix-jookia, guix-nonfree for those
> that really want to run it on their nonfree systems.

Is this the elephant in the room? Besides quality control, which is
necessary to make a distribution with thousands of packages maintainable
by just a few people, our only "restrictive" opinion is supporting only
free software - anything that is free software can go in. But this is
central to the project and a point where no compromises can be made.
Our goal is to support free software and only free software, which is
a promise to our users, supporters and ourselves.

Andreas