Re: Profiles/manifests-related command line interface enhancements

[Ludovic Courtès]

Howdy!

Konrad Hinsen <address@hidden> skribis:

>> 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.

OK, I understand.

>> 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,

We also have ‘guix show’, but there’s no standalone command equivalent
to ‘--list-installed’, ‘--list-available’, ‘--list-profiles’, and
‘--list-generations’.

> 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’s not entirely clear that a unified command would be easier to
use for newcomers.  For example, I’m not fond of “guix profile” as a
command name because that would mean users have to know what a “profile”
is before they’ve even installed their first package.

So I definitely agree we need to homogenize what ‘guix environment’ and
‘guix package’ currently provide, but I’m 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 ‘--ad-hoc’ becomes the default in ‘guix
     environment’, and add a ‘--devel’ (?) option for what’s currently
     the default.

     Tricky because of compatibility considerations, but would be an
     improvement, and goes in the direction of shortening the distance
     between ‘guix environment’ and ‘guix package’.

  2. Add that same ‘--devel’ option to ‘guix package’.

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 ‘guix channel add URL’?  Are you looking at this from a UI
perspective?

Are you also suggesting a “GuixHub” (I already hate that name :-)) 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 “delta”?), and I think it
could be useful.  The “potluck” 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’d
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’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.

OK, I see what you mean now regarding security.

(I don’t really agree with the “expert user” bit but we discussed that
in another fiber of this thread. :-))

Thank!

Ludo’.