From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22629: Channels! Date: Wed, 29 Aug 2018 16:25:51 +0200 Message-ID: <87efeh9rm8.fsf@gnu.org> References: <87vb5vsffd.fsf@gnu.org> <87pny2iks2.fsf@gnu.org> <877ekagtg9.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]:35345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv1R5-0002YC-Tm for bug-guix@gnu.org; Wed, 29 Aug 2018 10:27:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv1R3-0003z4-RG for bug-guix@gnu.org; Wed, 29 Aug 2018 10:27:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:60460) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fv1R0-0003x3-8u for bug-guix@gnu.org; Wed, 29 Aug 2018 10:27:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fv1R0-0004Q8-20 for bug-guix@gnu.org; Wed, 29 Aug 2018 10:27:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (Konrad Hinsen's message of "Wed, 29 Aug 2018 06:09:02 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Konrad Hinsen Cc: 22629@debbugs.gnu.org Hi Konrad, Konrad Hinsen skribis: > Look at the wider Linux world: there are people who want to live on > the bleeding edge and run Arch Linux, and there are others who value > stability and run CentOS. Today's Guix is more on the bleeding edge > side. My understanding of your commment is that you would like to make > sure it stays there. But that also means severely limiting Guix' > potential user base. Mark=E2=80=99s concern is not about whether packages are the latest version, etc. It=E2=80=99s about the constraints that could result from widespread development of channels outside Guix proper: technically all of Guix is just a library, so widespread development of external channels could force us Guix developers to keep the API stable. This, in turn, would limit our ability to make significant changes to Guix. > I see channels as an opportunity to have Guix "dialects" addressing > different needs and yet remain interoperable, although I am the first > to admit that I have no clear idea of how this would work out in > practice, more from the social than the technical point of view. But > the goal looks very attractive. Looking at my own use of Guix, I am > happy with its bleeding edge approach for the software I use for > research, but I'd much prefer a slower pace and more stability for > stuff like Emacs and TeX that are "boring infrastructure" for me. =E2=80=9CDialect=E2=80=9D sounds a bit strong, but I agree that such uses c= ould be interesting and beneficial, to users and to Guix. >> Even things as seemingly innocuous as moving a package from one module >> to another will impact these third-party channels, not to mention >> changing our internal APIs or making fundamental changes to the way >> packages are specified. > > So... could we reduce the dependence of package specifications on such > things? Package definitions use a small DSL that could be versioned, > allowing change while maintaining compatibility. Module dependencies > are more annoying, but do we need them? Package definitions are > grouped into modules mostly for convenience. All packages have > globally unique names, so could we use those to specify inputs? This is exactly that kind of issue Mark is concerned with: currently we don=E2=80=99t have to worry at all about this, and it=E2=80=99s great to ha= ve that freedom. I=E2=80=99d rather not build fancy mechanisms just for the sake of external channels, and I certainly don=E2=80=99t want to commit to API stability. We won=E2=80=99t break the API every day intentionally either, but my point is= that support for external channels will be =E2=80=9Cbest effort=E2=80=9D (as it = already is with GUIX_PACKAGE_PATH). I think it=E2=80=99s useful and practical nonethe= less. Ludo=E2=80=99.