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: Sat, 16 Nov 2019 23:27:30 +0100 Message-ID: <87r227qxf7.fsf@gnu.org> 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]:35362) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iW6Xa-00060P-Gk for guix-devel@gnu.org; Sat, 16 Nov 2019 17:27:39 -0500 In-Reply-To: (Konrad Hinsen's message of "Thu, 07 Nov 2019 08:46:23 +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@gnu.org Howdy! Konrad Hinsen skribis: >> 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 tha= n =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. OK, I understand. >> It=E2=80=99s great to have =E2=80=9Cguix install=E2=80=9D as an entry po= int; 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, We also have =E2=80=98guix show=E2=80=99, but there=E2=80=99s no standalone= command equivalent to =E2=80=98--list-installed=E2=80=99, =E2=80=98--list-available=E2=80=99, = =E2=80=98--list-profiles=E2=80=99, and =E2=80=98--list-generations=E2=80=99. > 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. To me it=E2=80=99s not entirely clear that a unified command would be easie= r to use for newcomers. For example, I=E2=80=99m not fond of =E2=80=9Cguix prof= ile=E2=80=9D as a command name because that would mean users have to know what a =E2=80=9Cpro= file=E2=80=9D is before they=E2=80=99ve even installed their first package. So I definitely agree we need to homogenize what =E2=80=98guix environment= =E2=80=99 and =E2=80=98guix package=E2=80=99 currently provide, but I=E2=80=99m not sure = where to go from there. Perhaps we need to discuss on concrete CLI proposals to have a better idea? Dunno! I have an actionable wishlist though: :-) 1. Arrange so that =E2=80=98--ad-hoc=E2=80=99 becomes the default in =E2= =80=98guix environment=E2=80=99, and add a =E2=80=98--devel=E2=80=99 (?) option f= or what=E2=80=99s currently the default. Tricky because of compatibility considerations, but would be an improvement, and goes in the direction of shortening the distance between =E2=80=98guix environment=E2=80=99 and =E2=80=98guix package= =E2=80=99. 2. Add that same =E2=80=98--devel=E2=80=99 option to =E2=80=98guix packag= e=E2=80=99. Thoughts? >> 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). You mean like =E2=80=98guix channel add URL=E2=80=99? Are you looking at t= his from a UI perspective? Are you also suggesting a =E2=80=9CGuixHub=E2=80=9D (I already hate that na= me :-)) that would collect channels? In Strasbourg in June we discussed the possibility to have a service to register free software channels, we even came up with a name for that (was it =E2=80=9Cdelta=E2=80=9D?), and I = think it could be useful. The =E2=80=9Cpotluck=E2=80=9D that Andy worked on a while= back goes in that direction too. > - Support for creating and managing channels without having to > descend to the file and repository level. Not entirely sure what you mean. Could you give examples of what you=E2=80= =99d type to create a channel, say? > - 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. So this thing would be a profile + services? >> 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. OK, I see what you mean now regarding security. (I don=E2=80=99t really agree with the =E2=80=9Cexpert user=E2=80=9D bit bu= t we discussed that in another fiber of this thread. :-)) Thank! Ludo=E2=80=99.