From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: A registry for distributed sources and binaries Date: Sun, 24 Jul 2016 22:35:43 +0200 Message-ID: <87wpka7p0g.fsf@elephly.net> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> <874m7hk6dz.fsf_-_@gnu.org> <20160724033027.GA20236@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRQ7w-0008FS-8S for guix-devel@gnu.org; Sun, 24 Jul 2016 16:35:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRQ7v-0000sx-5d for guix-devel@gnu.org; Sun, 24 Jul 2016 16:35:56 -0400 In-reply-to: <20160724033027.GA20236@thebird.nl> 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: Pjotr Prins Cc: guix-devel@gnu.org Hi Pjotr, > Registries solve the mentioned problems of GUIX_PACKAGE_PATH: > > 1. People are not aware about the work of others > 2. Slightly complicated (you need a Guix source tree etc.) > 3. No binary distribution When I first read your email I thought you proposed a mechanism that extends GUIX_PACKAGE_PATH. What you actually proposed seems a little too big and complicated from my point of view, but I am interested in discussing the idea of extending GUIX_PACKAGE_PATH. Currently, GUIX_PACKAGE_PATH depends on some manual work to be done first. Finding a third-party repository, downloading it, updating it separately from Guix itself (it won’t get updated via “guix pull”), setting the variable. When binary substitutes are involved some more steps are required: find and download the public key of the distributor (who might be running hydra or something like “guix publish”) and authorise it. Taken together it may seem a little too cumbersome compared to what other package managers do. To enable a third-party repository for Ubuntu, for example, I only need to run one command. When downloading packages I may also need to verify and accept a GPG key. 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? 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/” maybe?). Guix is automatically configured to use the modules from “~/.cache/guix/” 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. 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? What do others think? Is this something that would benefit the Guix project and its audience? ~~ Ricardo