From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: Re: Profiles/manifests-related command line interface enhancements Date: Thu, 07 Nov 2019 08:46:23 +0100 Message-ID: References: <87mudrxvs8.fsf@ambrevar.xyz> <87mudd59ho.fsf@gnu.org> <877e4glyc3.fsf@ambrevar.xyz> <87v9rxx8ri.fsf@gnu.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:470:142:3::10]:45603) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iScV6-000204-Hb for guix-devel@gnu.org; Thu, 07 Nov 2019 02:46:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iScV0-0001Wm-Tn for guix-devel@gnu.org; Thu, 07 Nov 2019 02:46:37 -0500 In-Reply-To: <87v9rxx8ri.fsf@gnu.org> 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Hi Ludo, > I think having ephemeral + persistent and declarative + imperative is > cool=E2=80=94I=E2=80=99d call that =E2=80=9Cflexible=E2=80=9D rather than= =E2=80=9Cmessy=E2=80=9D. :-) I agree. What's messy is how the concepts map to commands. How many Guix users understand that profiles are persistent environments, or environments ephemeral profiles? And how many understand what "guix environment -r" does exactly, and how it should be used? It took me a while to figure this out. What we have is two commands (package and environment) each designed for one main usage pattern, plus options to get something else. But even those options don't overlap completely in functionality. For example, how do I make a profile with the dependencies of a package? The current discussion started with adding more commands for different specific usage patterns. If we go that route the mess will become worse. > It=E2=80=99s great to have =E2=80=9Cguix install=E2=80=9D as an entry poi= nt; I=E2=80=99m sure it allows > us to reach out to more people, and that matters too. (I actually use > it, BTW, so it=E2=80=99s not an expert vs. newbie thing!) Me too :-) It's "guix package" that is the worst offender in my opinion. It does two distinct things: querying the package database and managing profiles. And now that we have "guix search" for queries, I'd like to see "guix package" go away, to be replaced by either "guix profile" for profile management, with as much overlap as possible in options with "guix environment", or by a single command that handles environments and profiles in a unified way. > I agree that sharing and publishing is important, and I think > manifests support that. They do, but not very well in my opinion. I think everything meant to be shared, published, and maintained should be accessible by name in a database. A channel, for example. Some ideas that could make this possible (and convenient): - Better support for adding/managing channels at the user account level. Users shouldn't have to edit Guile code (unless they want to). - Support for creating and managing channels without having to descend to the file and repository level. - Support for something one could call super-packages or named manifests. Named package groups that live in a channel (or a guix.scm distributed with software external to Guix). Perhaps parametrizable and/or containing configuration files, so you could put something like (nginx #:port 8080) into a manifest file. > I think we need to support =E2=80=9Cunions=E2=80=9D of manifests, and > that means (as always) supporting it at the API level and at the > command-line level (allowing for multiple =E2=80=98--manifest=E2=80=99 fl= ags). Yes, I agree. That's the easiest part. > What we=E2=80=99re now saying is =E2=80=9Clook, you can write a manifest,= and then you > can have it under version-control and publish it and it=E2=80=99s all up = to you > how you do that=E2=80=9D; but you seem to suggest that we should offer a > higher-level, more integrated solution, is that correct? Exactly. Every functionality that requires end-users to manage Guile code will always be restricted to expert users. Manifest files may look simple and understandable for simple cases, but if you expect users to install manifests downloaded from someone else, they need to be able to inspect them and be sure that installing the manifest file won't delete their user account. And that means they have to understand a lot about Guile. > Like, we would enforce certain conventions by default, perhaps have > direct Git integration so that one can refer to a =E2=80=9Cmanifest=E2=80= =9D just like > they refer to a channel, things like that. Do I get it right? Yes, that's the idea! Cheers, Konrad.