[RFC] A simple draft for channels

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

Hi Guix,

I’d like to retire GUIX_PACKAGE_PATH as the main way to get third-party
packages, because we can’t really keep track of packages that were added
or redefined in this way.  I want to replace it with slightly more
formal “channels”.

As a first implementation of channels I’d just like to have a channel
description file that records at least the following things:

* the channel name (all lower case, no spaces)
* a URL from where package definitions can be loaded (initially, this
  can be restricted to git repositories)

Optional fields:

* a description of the channel

* a URL from where substitutes for the packages can be obtained (this
  will be backed by “guix publish”)

* a mail address or URL to contact the maintainers of the channel, or to
  view the status of the channel

* the Guix git commit that was used when this channel was last
  updated.  This is useful when Guix upstream breaks the ABI or moves
  packages between modules.

On the Guix side we’d need to add the “guix channel” command, which
allows for adding, removing, updating, and downgrading channels.  Adding
a channel means fetching the channel description from a URL and storing
state in ~/.config/guix/channels/, and fetching the git repo it
specifies (just like what guix pull does: it’s a git frontend).  It also
authorizes the the substitute server’s public key.

Internally, it’s just like GUIX_PACKAGE_PATH in that the repos are used
to extend the modules that Guix uses.  Unlike GUIX_PACKAGE_PATH,
however, we now have a way to record the complete state of Guix,
including any extensions: the version of Guix and all active channels
with their versions.  We would also have a way to fetch substitutes from
channels without having to “globally” enable new substitute servers and
authorize their keys.  (Is this safe?  Can we have per-user extensions
to the set of public keys that are accepted?)

Downsides: Guix has no stable ABI, so channels that are not up-to-date
will break with newer versions of Guix.  Moving around packages to
different modules might break channels.  That’s okay.  It’s still an
improvement over plain GUIX_PACKAGE_PATH.

I don’t think it has to be more complicated than that.  What do you
think?

--
Ricardo