Re: A registry for distributed sources and binaries

[Pjotr Prins <pjotr.public12@thebird.nl>]

On Sun, Jul 24, 2016 at 10:35:43PM +0200, Ricardo Wurmus wrote:
> 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?

Thanks Ricardo, that is exactly what I am proposing.

> 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.

Yes.

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

That is it.

> What do others think?  Is this something that would benefit the Guix
> project and its audience?

I think it would make Guix cooler than anything out there. We already
do distributed binary distribution (awesome!), now we could do
federated source distribution. Key thing is that we make people
*autonomous* and encourage *diversity*.

Andreas: this is not about non-free software.  We *are* using
GUIX_PACKAGE_PATH for deployment. We have 140+ free bioinformatics
packages sitting in a tree. I am totally happy using that. We have
trouble getting to install our software. I don't have the stamina
getting these packages into core (an estimated another 40 days of work
and back-and-forths? It does not scale).

Ricardo: the one thing I would like to add is package discovery. In a
federated environment we want to avoid duplication of work and say I
had an Elixir package in my tree, it could be a good starting point
for someone wanting to bring it into core.

Support for multiple GUIX_PACKAGE_PATH's would be first priority.
Binary support second and discovery third. 

Thanks again for your constructive suggestion,

Pj.
--