unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: A registry for distributed sources and binaries
Date: Sun, 24 Jul 2016 05:30:27 +0200	[thread overview]
Message-ID: <20160724033027.GA20236@thebird.nl> (raw)
In-Reply-To: <874m7hk6dz.fsf_-_@gnu.org>

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. People are not aware about the work of others
2. Slightly complicated (you need a Guix source tree etc.)
3. No binary distribution

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.

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
   and multiple authors.

2. Each repo in the registry can create package definitions online

3. When someone wants to use a registry, run guix with

   guix package --registry http://biogems.info/bioinformatics.scm -A ruby

   i.e. to list all packages that have ruby, including the ones in
   that registry. Likewise for an incubator registry:

   guix package --registry http://incubator-guix.org/unstable.scm -A ruby

   generates a different list.

4. At install of a registry package, the entry can (optionally) point to a Guix
   publish server with its key, so we can do 'add key' and 'install
   binary or source package' for the registry. This way we get trusted
   binary distribution for distributed packages in registries.

This would also compete nicely with the likes of Docker, especially
when using containers, in a more secure way.

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

It also takes away the centralized approach of GNU Guix for those who
don't want that - though the main tree will still be developed against
for building a solid distribution etc. I.e., the core stuff continues,
but people are free to try other routes. All a registry needs to
provide is a guile file containing information of the package(s) whith
a pointer to online pointers of documentation, overview, guix publish
server and key.

Personally I think this will be very exciting. We can have a
metaregistry that lists all these packages so everyone can track them.

Scalability. Less opinion, less duplication of work. True incubators.

Pj.

  parent reply	other threads:[~2016-07-24  3:34 UTC|newest]

Thread overview: 87+ 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       ` Pjotr Prins [this message]
2016-07-24  5:10         ` A registry for distributed sources and binaries Tobias Geerinckx-Rice
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
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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=20160724033027.GA20236@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).