all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tobias Geerinckx-Rice <me@tobias.gr>
To: "Pjotr Prins" <pjotr.public12@thebird.nl>,
	"Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: A registry for distributed sources and binaries
Date: Sun, 24 Jul 2016 07:10:44 +0200	[thread overview]
Message-ID: <2eb889dd-8abc-70a2-cabb-a81ac5b1b60b@tobias.gr> (raw)
In-Reply-To: <20160724033027.GA20236@thebird.nl>

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.

  reply	other threads:[~2016-07-24  5:11 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-21  1:39 (unknown) Unknown, Pjotr Prins
2016-07-21  1:42 ` [PATCH] gnu: Add elixir Pjotr Prins
2016-07-21 11:43   ` Ben Woodcroft
2016-07-21 12:00     ` Pjotr Prins
2016-07-22  5:26     ` Leo Famulari
2016-07-22 12:55       ` Ludovic Courtès
2016-07-22 14:12         ` Leo Famulari
2016-07-21 12:51 ` none Ludovic Courtès
2016-07-22  0:41   ` none Pjotr Prins
2016-07-22  2:06     ` none Pjotr Prins
2016-07-22  3:25       ` none Jookia
2016-07-22  3:48       ` none Leo Famulari
2016-07-22  4:48       ` none Tobias Geerinckx-Rice
2016-07-22 11:07         ` none Pjotr Prins
2016-07-22 12:23           ` none Ricardo Wurmus
2016-07-22 12:50             ` none Jookia
2016-07-22 21:19               ` none Leo Famulari
2016-07-24  4:17                 ` none Jookia
2016-07-24  6:35                   ` none Leo Famulari
2016-07-24  7:47                     ` none Jookia
2016-07-24 16:52               ` none Christopher Allan Webber
2016-07-24 17:03                 ` none Andreas Enge
2016-07-22  8:15     ` none Roel Janssen
2016-07-22 14:07       ` none Leo Famulari
2016-07-22 14:15         ` none Vincent Legoll
2016-07-22 16:13       ` none Ludovic Courtès
2016-07-22 16:38         ` none myglc2
2016-07-23  7:03           ` none Tomáš Čech
2016-07-22 16:02     ` Review process Ludovic Courtès
2016-07-23  2:24       ` Pjotr Prins
2016-07-23  9:05         ` Alex Kost
2016-07-23  9:51           ` Mathieu Lirzin
2016-07-24  8:02             ` Alex Kost
2016-07-24 10:38               ` Mathieu Lirzin
2016-07-24 14:09               ` Ludovic Courtès
2016-07-24  3:30       ` A registry for distributed sources and binaries Pjotr Prins
2016-07-24  5:10         ` Tobias Geerinckx-Rice [this message]
2016-07-24  5:16           ` Pjotr Prins
2016-07-24  5:24         ` Pjotr Prins
2016-07-24  5:29         ` Mark H Weaver
2016-07-24  5:48           ` Jookia
2016-07-24  6:37             ` Tobias Geerinckx-Rice
2016-07-24  7:49               ` Jookia
2016-07-24 20:02             ` Ricardo Wurmus
2016-07-24  6:28           ` Tobias Geerinckx-Rice
2016-07-24  7:02             ` Pjotr Prins
2016-07-24  7:29           ` Leo Famulari
2016-07-24  7:41             ` Pjotr Prins
2016-07-24  9:50           ` Mathieu Lirzin
2016-07-24 22:46           ` Ludovic Courtès
2016-07-24 13:58         ` Andreas Enge
2016-07-24 15:21           ` Jookia
2016-07-24 15:58             ` Andreas Enge
2016-07-24 17:18             ` replying to a message of a mailing list you were not subscribed to Danny Milosavljevic
2016-07-24 17:25               ` Danny Milosavljevic
2016-07-25  5:38                 ` Ricardo Wurmus
2016-07-25  7:34                   ` icecat "mailto" handler does not work - and cannot be reconfigured by user Danny Milosavljevic
2020-10-13 13:23                     ` bug#24066: " Maxim Cournoyer
2020-10-16  7:12                     ` Brendan Tildesley
2020-10-26 16:39                     ` Jonathan Brielmaier
2016-07-24 18:50             ` A registry for distributed sources and binaries John Darrington
2016-07-25  9:14             ` Replying to bug reports Ludovic Courtès
2016-07-25  8:25           ` A registry for distributed sources and binaries Andy Wingo
2016-07-25 22:00             ` Reviewer assignment Ludovic Courtès
2016-07-24 20:35         ` A registry for distributed sources and binaries Ricardo Wurmus
2016-07-25  2:10           ` Pjotr Prins
2016-07-25  3:42             ` Tobias Geerinckx-Rice
2016-07-25  4:57               ` Pjotr Prins
2016-07-25  7:18           ` Tomáš Čech
2016-07-25  9:21           ` Ludovic Courtès
2016-07-26  3:40             ` Pjotr Prins
2016-07-26  3:45               ` Pjotr Prins
2016-07-25  6:13 ` [PATCH] Add Elixir (was: ) Ricardo Wurmus
2016-07-25  6:31   ` Pjotr Prins
2016-07-28  7:27     ` Ricardo Wurmus
2016-07-28  8:30       ` Vincent Legoll
2016-07-28 10:35       ` Pjotr Prins
2016-07-28 20:35         ` Ricardo Wurmus
2016-07-29  2:38           ` Pjotr Prins
2016-07-29  6:32             ` Vincent Legoll
2016-08-02  8:56             ` Ricardo Wurmus
2016-08-02 14:30               ` Pjotr Prins
2016-08-02  8:44     ` [PATCH] Add Elixir Ricardo Wurmus
2016-08-02 14:29       ` Pjotr Prins
2016-08-02 17:26       ` Ludovic Courtès
2016-08-02 21:25         ` Ricardo Wurmus
2016-08-03  4:41           ` Pjotr Prins
2016-08-09 11:18           ` Pjotr Prins
2016-08-09 11:58             ` Alex Sassmannshausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2eb889dd-8abc-70a2-cabb-a81ac5b1b60b@tobias.gr \
    --to=me@tobias.gr \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.