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
