Re: Profiles/manifests-related command line interface enhancements

[Konrad Hinsen <konrad.hinsen@fastmail.net>]

Hi Ludo,

> I think having ephemeral + persistent and declarative + imperative is
> cool—I’d call that “flexible” rather than “messy”.  :-)

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’s great to have “guix install” as an entry point; I’m sure it allows
> us to reach out to more people, and that matters too.  (I actually use
> it, BTW, so it’s 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 “unions” of manifests, and
> that means (as always) supporting it at the API level and at the
> command-line level (allowing for multiple ‘--manifest’ flags).

Yes, I agree. That's the easiest part.

> What we’re now saying is “look, you can write a manifest, and then you
> can have it under version-control and publish it and it’s all up to you
> how you do that”; 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 “manifest” just like
> they refer to a channel, things like that.  Do I get it right?

Yes, that's the idea!

Cheers,
  Konrad.