Re: A registry for distributed sources and binaries

[Ricardo Wurmus <rekado@elephly.net>]

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 GUIX_PACKAGE_PATH.  What you actually proposed seems a little
too big and complicated from my point of view, but I am interested in
discussing the idea of extending GUIX_PACKAGE_PATH.

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 binary substitutes are involved some more steps are required: find
and download the public key of the distributor (who might be running
hydra or something like “guix publish”) and authorise it.

Taken together it may seem a little too cumbersome compared to what
other package managers do.  To enable a third-party repository for
Ubuntu, for example, I only need to run one command.  When downloading
packages I may also need to verify and accept a GPG key.

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 substitutes?

Here are some concrete proposals:

* Add a “guix config” command, which allows users to modify the
  behaviour of their instance of Guix.

* Support adding repositories via “guix config”.  A “repository” is a
  remote set of Guile modules and (optionally) an public endpoint of
  “guix publish” through which substitutes of only those packages that
  are defined in the repository’s modules can be downloaded.

* The first time a repository is accessed, the specified modules are
  cloned and stored in a per-user state directory
  (“~/.cache/guix/<domain>” maybe?).  Guix is automatically configured
  to use the modules from “~/.cache/guix/<domain>” in addition to what
  is on GUIX_PACKAGE_PATH.  Additionally, the distribution public key
  for binary substitutes is fetched from a well-known location (if
  applicable) and users are asked to confirm.

* When a user runs “guix pull” all enabled repositories are also
  updated.  Otherwise the cached copy from last access is used.

* Update “guix --version” to also return the version of each configured
  repository.

* Add a command line switch “--vanilla” (or similar) to disable any
  custom configuration and any configured repositories.

With the mechanism described above it would be less intimidating for
users to add sources of Guix packages (or Guix features) and download
binary substitutes.

Third parties can distribute package descriptions (or experimental
features) along with binary substitutes by simply hosting the modules
and running “guix publish”.  The Guix project doesn’t need to care.
Exactly how third-party collections are managed is completely up to the
respective maintainers.

While I feel strongly that we should focus our efforts on Guix upstream
I also think that it may be useful and convenient to expand the
GUIX_PACKAGE_PATH feature.

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?

~~ Ricardo