From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: A registry for distributed sources and binaries Date: Mon, 25 Jul 2016 04:10:27 +0200 Message-ID: <20160725021027.GA24239@thebird.nl> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> <874m7hk6dz.fsf_-_@gnu.org> <20160724033027.GA20236@thebird.nl> <87wpka7p0g.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRVPA-0005zs-BB for guix-devel@gnu.org; Sun, 24 Jul 2016 22:14:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRVP7-0008TD-2V for guix-devel@gnu.org; Sun, 24 Jul 2016 22:14:04 -0400 Content-Disposition: inline In-Reply-To: <87wpka7p0g.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org 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: >=20 > * Add a =E2=80=9Cguix config=E2=80=9D command, which allows users to mo= dify the > behaviour of their instance of Guix. >=20 > * Support adding repositories via =E2=80=9Cguix config=E2=80=9D. A =E2= =80=9Crepository=E2=80=9D is a > remote set of Guile modules and (optionally) an public endpoint of > =E2=80=9Cguix publish=E2=80=9D through which substitutes of only thos= e packages that > are defined in the repository=E2=80=99s modules can be downloaded. >=20 > * The first time a repository is accessed, the specified modules are > cloned and stored in a per-user state directory > (=E2=80=9C~/.cache/guix/=E2=80=9D maybe?). Guix is automatic= ally configured > to use the modules from =E2=80=9C~/.cache/guix/=E2=80=9D in a= ddition 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. >=20 > * When a user runs =E2=80=9Cguix pull=E2=80=9D all enabled repositories= are also > updated. Otherwise the cached copy from last access is used. >=20 > * Update =E2=80=9Cguix --version=E2=80=9D to also return the version of= each configured > repository. >=20 > * Add a command line switch =E2=80=9C--vanilla=E2=80=9D (or similar) to= disable any > custom configuration and any configured repositories. >=20 > 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 =E2=80=9Cguix publish=E2=80=9D. The Guix project doesn=E2=80= =99t need to care. > Exactly how third-party collections are managed is completely up to the > respective maintainers. >=20 > 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. >=20 > 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.=20 Thanks again for your constructive suggestion, Pj. --=20