From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Profiles/manifests-related command line interface enhancements Date: Wed, 06 Nov 2019 18:07:09 +0100 Message-ID: <87k18dvsqq.fsf@gnu.org> References: <87mudrxvs8.fsf@ambrevar.xyz> <87mudd59ho.fsf@gnu.org> <877e4glyc3.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42139) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSOm2-0007ws-VF for guix-devel@gnu.org; Wed, 06 Nov 2019 12:07:16 -0500 In-Reply-To: (Konrad Hinsen's message of "Tue, 05 Nov 2019 17:05:08 +0100") 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: Konrad Hinsen Cc: Guix Devel Hi Konrad, Konrad Hinsen skribis: > Take the typical example from Docker tutorials: bundling a Web server > with some Web application and a database. It's easy to make a manifest > file for collecting the required packages. But it would make more sense > to me to have a module in a Guix channel that defines a parametrizable > super-package for the Web application that has no source code of its own > but various inputs and perhaps configuration files. Users can then > install several Web apps bundled in this fashion, sharing the Web > server. This kind of composition is not possible (currently) with > manifest files. I agree this is an important use case. It seems to me that the problem here is being able to aggregate more than just packages. A manifest can contain any lowerable object, not just packages, but then, does it make much sense to use a manifest (and a profile) in this case? The Web application example above seems to be somewhere between a mere and an full-blown . Perhaps we need an intermediate abstraction that bundles together a profile along with some lightweight services? Or, to put it differently, how do we define =E2=80=9Csuper-package=E2=80=9D? >> Profiles are managed by Guix, isn't it? > > Sure, but how exactly? Right now, a profile is a directory anywhere in > the file system that Guix knows about. Recent discussions have proposed > alternatives, such as keeping all of a user's profile in some directory > defined by convention and referring to them by name. What's the better > way to use as a default? I don't know, but I think we should discuss it > rather than adding new sub-commands with different behavior and thus > adding to the mess. =E2=80=98guix package --list-profiles=E2=80=99 was added to improve this si= tuation where there=E2=80=99s no enforced convention. The question seems to be whether we should add more convention and less configuration. I=E2=80=99m often reluctant to that, preferring self-contained commands whe= re all the files involved appear on the command line. However, I agree that it=E2=80=99s a tradeoff and there=E2=80=99s a balance to be found to m= ake the CLI practical and convenient without making it obscure. To that end, we should probably usefully move from =E2=80=9Czero conventions=E2=80=9D to = =E2=80=9Csome conventions enforced=E2=80=9D to improve over the current situation. Examples of conventions discussed before: =E2=80=A2 Referring to profiles by name, meaning that users would no long= er explicitly manipulate symlinks that live anywhere on the file system. =E2=80=A2 Having =E2=80=9Cguix environment=E2=80=9D without arguments loa= d an =E2=80=98environment.scm=E2=80=99 file (or similar) from the current di= rectory. Are these things you have in mind? Anything else? We should boil that discussion down to a list of things to implement. :-) Thanks! Ludo=E2=80=99.