From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: guix is the guildhall that we always wanted! Date: Thu, 16 Mar 2017 23:24:22 +0100 Message-ID: <87o9x0uag9.fsf@gnu.org> References: <87zigl3wph.fsf@pobox.com> <87a88kanjq.fsf@netris.org> 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]:59379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1codot-0001Lb-5W for guix-devel@gnu.org; Thu, 16 Mar 2017 18:24:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1codos-0002H5-C5 for guix-devel@gnu.org; Thu, 16 Mar 2017 18:24:31 -0400 In-Reply-To: <87a88kanjq.fsf@netris.org> (Mark H. Weaver's message of "Thu, 16 Mar 2017 18:01:45 -0400") 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: Mark H Weaver Cc: Andy Wingo , guix-devel@gnu.org, guile-user@gnu.org Hello! Mark H Weaver skribis: > Andy Wingo writes: > >> So! My proposal for this new "guildhall" would be: >> >> 1. a web service >> >> 2. on which users registers projects >> >> 3. a project is a name + a git repository with a /package.scm file >> >> 4. the package.scm contains Guix package definitions for that project > > We need to keep all Guix package definitions within Guix itself, for the > same reason that Linux (the kernel) developers insist on keeping all > device drivers within a single monolithic tree. If we start encouraging > a decentralized approach, that would result in strong pressure on us to > freeze our API, which includes even such details as which module each > package is exported from. This would drastically reduce the freedom > Guix has to evolve the way its packages are specified. I think having repos maintained elsewhere is OKish, but it=E2=80=99s true t= hat it requires people who maintain those repos to follow closely what=E2=80=99s going on in Guix proper because we=E2=80=99re not guaranteeing API stabilit= y. There=E2=80=99s a couple of ways to mitigate potential API instability: usi= ng =E2=80=98specification->package=E2=80=99 instead of referring to packages b= y variable name, and using (guix) and (gnu) instead of more specific modules. So I think having an external repo for guildhall would be possible, but we need to make sure the connection to Guix APIs is loose enough. Also, guildhall would be a privileged =E2=80=9Ccustomer=E2=80=9D I suppose.= :-) Ludo=E2=80=99.