Re: A registry for distributed sources and binaries

2016-07-25 Thread Pjotr Prins
On Tue, Jul 26, 2016 at 05:40:49AM +0200, Pjotr Prins wrote: > On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote: > > I like the idea! (With the caveat that, again, external repos can break > > anytime.) > > > > Partly related to that: > >

Re: A registry for distributed sources and binaries

2016-07-25 Thread Pjotr Prins
On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote: > I like the idea! (With the caveat that, again, external repos can break > anytime.) > > Partly related to that: > . Actually very much related because a git pull attached to a

Re: A registry for distributed sources and binaries

2016-07-25 Thread Ludovic Courtès
Hello, Ricardo Wurmus skribis: > Currently, GUIX_PACKAGE_PATH depends on some manual work to be done > first. Finding a third-party repository, downloading it, updating it > separately from Guix itself (it won’t get updated via “guix pull”), > setting the variable. > > When

Re: A registry for distributed sources and binaries

2016-07-25 Thread Andy Wingo
On Sun 24 Jul 2016 15:58, Andreas Enge writes: > 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 :-) Could we just focus on this problem perhaps? One of the issues

Re: A registry for distributed sources and binaries

2016-07-25 Thread Tomáš Čech
On Sun, Jul 24, 2016 at 10:35:43PM +0200, Ricardo Wurmus wrote: What do you think about that? Does this align with your vision? What do others think? Is this something that would benefit the Guix project and its audience? I like the idea a lot. I'm only concerned with security of such

Re: A registry for distributed sources and binaries

2016-07-24 Thread Pjotr Prins
On Mon, Jul 25, 2016 at 05:42:20AM +0200, Tobias Geerinckx-Rice wrote: > Pjotr, > > On 2016-07-25 04:10, Pjotr Prins wrote: > >Support for multiple GUIX_PACKAGE_PATH's would be first priority. > > I'm taking it you're not talking about colon-separation (which > is already supported, though I

Re: A registry for distributed sources and binaries

2016-07-24 Thread Tobias Geerinckx-Rice
Pjotr, On 2016-07-25 04:10, Pjotr Prins wrote: Support for multiple GUIX_PACKAGE_PATH's would be first priority. I'm taking it you're not talking about colon-separation (which is already supported, though I haven't tried it) but something more? I'm interested :-) Kind regards, T G-R --

Re: A registry for distributed sources and binaries

2016-07-24 Thread Pjotr Prins
On Sun, Jul 24, 2016 at 10:35:43PM +0200, Ricardo Wurmus wrote: > Could it be enough if Guix offered a simpler way to fetch package > definitions and (optionally) binary substitutes from a third party who > maintains both the package definitions and (optionally) distributes > pre-built binary

Re: A registry for distributed sources and binaries

2016-07-24 Thread Ludovic Courtès
Hi, Mark H Weaver skribis: > It's crucially important to the future vitality of this project that we > retain our freedom to evolve the design of Guix, the way packages are > specified in Guix, as well as the set of core packages. These freedoms > will be drastically curtailed

Re: A registry for distributed sources and binaries

2016-07-24 Thread Ricardo Wurmus
Hi Pjotr, > Registries solve the mentioned problems of GUIX_PACKAGE_PATH: > > 1. People are not aware about the work of others > 2. Slightly complicated (you need a Guix source tree etc.) > 3. No binary distribution When I first read your email I thought you proposed a mechanism that extends

Re: A registry for distributed sources and binaries

2016-07-24 Thread Ricardo Wurmus
Jookia <166...@gmail.com> writes: > I think the clearest system is a way to have multiple guixes installed at > once. > Other package managers need not do this, but as long as the daemon > compatiblity > is kept it should be fine. There could be a guix-jookia, guix-nonfree for > those > that

Re: A registry for distributed sources and binaries

2016-07-24 Thread John Darrington
On Mon, Jul 25, 2016 at 01:21:50AM +1000, Jookia wrote: Even worse, if I want to reply to an issue on a mailing list that I'm not subscribed to, it's difficult. I still haven't figured it out, maybe you can go to the archive and download an mbox and look at the reference and ask

Re: A registry for distributed sources and binaries

2016-07-24 Thread Andreas Enge
Hello again, On Mon, Jul 25, 2016 at 01:21:50AM +1000, Jookia wrote: > An issue tracker that you can reply to by the web would be much much better, > because there's less things to go wrong and less ways to be shamed for. I've > suggested this many times and the only responses I've heard are 'no'

Re: A registry for distributed sources and binaries

2016-07-24 Thread Jookia
On Sun, Jul 24, 2016 at 03:58:28PM +0200, Andreas Enge wrote: > 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

Re: A registry for distributed sources and binaries

2016-07-24 Thread Andreas Enge
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

Re: A registry for distributed sources and binaries

2016-07-24 Thread Mathieu Lirzin
Hi, Mark H Weaver writes: > Pjotr Prins writes: > >> How about the following: >> >> 1. Separate from the GNU project, we create a number of registries of >>online git repos without opinion (i.e., anything goes, it is up to >>the authors). A

Re: A registry for distributed sources and binaries

2016-07-24 Thread Jookia
On Sun, Jul 24, 2016 at 08:37:34AM +0200, Tobias Geerinckx-Rice wrote: > Eeh. IMO, let's not drag unfree software into this. It's not the > motivation, and I can't see it helping anyone's cause or mood. It's the only example I can think of easily that Guix will not merge in any case, yet users

Re: A registry for distributed sources and binaries

2016-07-24 Thread Pjotr Prins
On Sun, Jul 24, 2016 at 03:29:49AM -0400, Leo Famulari wrote: > If we did choose to present a stable API, we would need people to > maintain it. 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

Re: A registry for distributed sources and binaries

2016-07-24 Thread Leo Famulari
On Sun, Jul 24, 2016 at 01:29:20AM -0400, Mark H Weaver wrote: > Long ago, the Linux developers made a conscious decision to not support > out-of-tree drivers, for much the same reasons. Many times over the > years, they have made changes to their internal APIs that required > corresponding

Re: A registry for distributed sources and binaries

2016-07-24 Thread Pjotr Prins
On Sun, Jul 24, 2016 at 08:28:30AM +0200, Tobias Geerinckx-Rice wrote: > > if we support a decentralized system of externally-managed > > repositories. > > No. Break them. > > If you're running an external Guix repository and don't bother to follow > the main development branch(es) with some

Re: A registry for distributed sources and binaries

2016-07-24 Thread Tobias Geerinckx-Rice
OK, one more... On 24/07/2016 7:48, Jookia wrote: > I think the clearest system is a way to have multiple guixes > installed at once. Other package managers need not do this, but as > long as the daemon compatiblity is kept it should be fine. There > could be a guix-jookia, guix-nonfree for

Re: A registry for distributed sources and binaries

2016-07-24 Thread Tobias Geerinckx-Rice
Mark, On 24/07/2016 7:29, Mark H Weaver wrote: > Long ago, the Linux developers made a conscious decision to not > support out-of-tree drivers, for much the same reasons. Many times > over the years, they have made changes to their internal APIs that > required corresponding changes to a

Re: A registry for distributed sources and binaries

2016-07-23 Thread Jookia
On Sun, Jul 24, 2016 at 01:29:20AM -0400, Mark H Weaver wrote: > It's crucially important to the future vitality of this project that we > retain our freedom to evolve the design of Guix, the way packages are > specified in Guix, as well as the set of core packages. These freedoms > will be

Re: A registry for distributed sources and binaries

2016-07-23 Thread Mark H Weaver
Pjotr Prins writes: > How about the following: > > 1. Separate from the GNU project, we create a number of registries of >online git repos without opinion (i.e., anything goes, it is up to >the authors). A registry can contain the work of multiple packages >

Re: A registry for distributed sources and binaries

2016-07-23 Thread Pjotr Prins
Another interesting thought would be to even generalize the idea of plugins: guix package --plugin http://URL/registry-plugin.scm -A ruby -- --registry http://my-registry/list.scm guix package --plugin http://URL/registry-plugin.scm -i ruby-package -- --registry http://my-registry/list.scm

Re: A registry for distributed sources and binaries

2016-07-23 Thread Pjotr Prins
On Sun, Jul 24, 2016 at 07:10:44AM +0200, Tobias Geerinckx-Rice wrote: > > 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. You are right. I am using this to fixate the Guix

Re: A registry for distributed sources and binaries

2016-07-23 Thread 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

A registry for distributed sources and binaries

2016-07-23 Thread Pjotr Prins
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'. The main problems with the current GUIX_PACKAGE_PATH approach are 1.