From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: [RFC] A simple draft for channels Date: Fri, 19 Jan 2018 12:30:49 +0100 Message-ID: <20180119113049.GA5328@thebird.nl> References: <87bmhq6ytg.fsf@mdc-berlin.de> 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]:39822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecUw0-00023x-D6 for guix-devel@gnu.org; Fri, 19 Jan 2018 06:34:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecUvv-0007vM-DN for guix-devel@gnu.org; Fri, 19 Jan 2018 06:34:12 -0500 Received: from mail.thebird.nl ([95.154.246.10]:43157) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ecUvv-0007tz-3W for guix-devel@gnu.org; Fri, 19 Jan 2018 06:34:07 -0500 Content-Disposition: inline In-Reply-To: <87bmhq6ytg.fsf@mdc-berlin.de> 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 Fri, Jan 19, 2018 at 09:24:27AM +0100, Ricardo Wurmus wrote: > Hi Guix, >=20 > I=E2=80=99d like to retire GUIX_PACKAGE_PATH as the main way to get thi= rd-party > packages, because we can=E2=80=99t really keep track of packages that w= ere added > or redefined in this way. I want to replace it with slightly more > formal =E2=80=9Cchannels=E2=80=9D. >=20 > As a first implementation of channels I=E2=80=99d just like to have a c= hannel > description file that records at least the following things: >=20 > * 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) Name and URL can be one. I would think the URL+branch or git tag is unique for the channel. A channel can still be named by a user, but it need not be specified. Like git does with branches and remote repos. E.g. guix channel add bioinfo1 git-URL So the user choses the name. > Optional fields: >=20 > * a description of the channel >=20 > * a URL from where substitutes for the packages can be obtained (this > will be backed by =E2=80=9Cguix publish=E2=80=9D) >=20 > * a mail address or URL to contact the maintainers of the channel, or t= o > view the status of the channel >=20 > * 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. The last is critical. One thing we need to think through is that we don't want to build the full guix repo since it slow and will take more and more time. Would it be possible to package the binary .go files and use those on the go since they are fixated anyway? I presume they are system independent (but not arch independent - but I think different arch will have different channels anyway). The package definition can be hosted inside the git repo as a guix-channel.scm file. When the user adds a channel we can fetch this info. > On the Guix side we=E2=80=99d need to add the =E2=80=9Cguix channel=E2=80= =9D command, which > allows for adding, removing, updating, and downgrading channels. Addin= g > 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=E2=80=99s a git frontend).= It also > authorizes the the substitute server=E2=80=99s public key. That would be wonderful. Maybe make it an --auto-authorize switch for those who choose to live dangerously. > Internally, it=E2=80=99s 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. =20 Exactly. > We would also have a way to fetch substitutes from > channels without having to =E2=80=9Cglobally=E2=80=9D enable new substi= tute servers and > authorize their keys. (Is this safe? Can we have per-user extensions > to the set of public keys that are accepted?) >=20 > Downsides: Guix has no stable ABI, so channels that are not up-to-date > will break with newer versions of Guix. =20 Popular channels will move along, I have no doubt. > Moving around packages to > different modules might break channels. That=E2=80=99s okay. It=E2=80= =99s still an > improvement over plain GUIX_PACKAGE_PATH. >=20 > I don=E2=80=99t think it has to be more complicated than that. What do= you > think? I think it is spot on. Some devil in details, I am sure. We can also build a web page where we can list channels, test-run them, and their libre-state. In principle build-farm support could be added for libre-channels. It would help GNU Guix move forward as a generalized solution. You will not believe the pain I went through with Fred just to install a huge GUIX_PACKAGE_PATH package. And we both already use Guix and can write packages!=20 In the next phase I can add support for relocatable packages attached to a channel. We could get to the point that: 1. Install Guix with proot support 2. Fetch channel 3. Install binary package from channel (native compiled and optimized) into proot So far will work for all software that runs in proot. Next 4. Relocate binary And we have a local optimized software without ever getting root because the relocated binary won't need proot. It won't work for all software though. But for most computational tools it will. Anyway, separate story. Even a native channel is a huge win. We can start hacking at FOSDEM. I am happy to participate. Pj.