Re: [RFC] A simple draft for channels

[Jelle Licht]

2018-01-19 9:24 GMT+01:00 Ricardo Wurmus <address@hidden>:

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

I am not sure, but I think we need to be able to ensure that these 'new' substitute servers

will only be used to get substitutes for the derivations in that specific channel.

I am not sure how easy it will be to make sure this will be the case, but I guess we do not

want to give any user-defined the possibility to 'overwrite' substitutes for existing derivations

from system-trusted substitute servers.

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.

We might be able to mitigate this by using by using Semantic Versioning [1]

on a best-effort basis. Perhaps (some) changes to the abi could even be picked up and warned

about by a tool not unlike the one used to generate the package listings for new releases. I am

thinking of things like:

- A package was renamed (so the previous named version no longer exists)

- A package was moved

 

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

--
Ricardo

In general, I like it and would love to play around with this soon.

- Jelle

[1]: https://semver.org/