Re: Guix CLI, thoughts and suggestions

[Ian Eure]

Hi Carlo,

Thank you for the thoughtful reply.

Carlo Zancanaro <carlo@zancanaro.id.au> writes:

> Hi Ian,
>
> Much of what you've written is fair, and I'm sure that Guix's 
> commands
> could be better organised. I'm not really involved in Guix 
> development,
> but I think there are two "inconsistencies" that you've 
> mentioned which
> can be explained.
>
> On Mon, Jan 15 2024, Ian Eure wrote:
> > Some examples of where I think Guix could do better.  This is 
> > an
> > illustrative list, not an exhaustive one.
> >
> > Inconsistent organization
> > =========================
> >
> > Most package-related commands are under `guix package', but 
> > many are
> > sibling commands.  Examples are `guix size', `guix lint', `guix 
> > hash',
> > etc.
>
> I think the real inconsistency here is that `guix package' is 
> poorly
> named. This command really operates on profiles, and performs 
> operations
> (install, remove, list, etc.) on those profiles. Packages are 
> given as
> arguments to this command.
>
> The other commands operate on, and show the properties of, 
> packages.
> Similarly with `guix build'.

Yes, I agree the behavior makes a bit more sense from that 
viewpoint.  However, it does have non-profile-related things in 
it, such as `--show' and `--search'.  This is getitng into another 
thing I’ve seen a bit of, which is overloaded commands -- ones 
that do multiple things that are unrelated or tangentally related. 
But, I didn’t have a good example, and my message was long enough 
already.



> > Inconsistency between verbs and options
> > =======================================
>
> > ... For example, installing a package is `guix package -i foo' 
> > rather
> > than `guix package install foo', removing is `guix package -r 
> > foo'
> > rather than `guix package remove foo', and listing installed 
> > packages
> > is `guix package -I' rather than `guix package installed' (or
> > similar).
>
> The specific example of `guix package' might be explained by 
> considering
> it as a single transaction to update the profile. The command 
> `guix
> package' really says "perform a transaction on the profile", and 
> the
> options are the commands in the transaction. Since there can be 
> multiple
> commands, and the command names look like package names, they 
> are
> provided as options.
>
> This doesn't fully explain the behaviour. In particular the 
> example you
> give:
>
> > This means that users can express commands which *seem* like 
> > they
> > should work, but do not.  For example `guix package -i emacs -r
> > emacs-pgtk -I' represents a command to 1) install emacs 2) 
> > remove
> > emacs-pgtk 3) list installed packages (which would verify the 
> > previous
> > two operations occurred). ...
>
> seems reasonable to have working within the view of `guix 
> package' as a
> transactional operation.

I agree that this would make sense, but my understanding is that 
`guix package' doesn’t work like that -- it only performs the 
final operation in the list.  IMO, it should either do 
*everything* the commands specify, or print an error and take no 
action.


> It's also worth noting that there are convenience shortcuts in 
> `guix
> install' and `guix remove'.
>
> > It seems like a lot of work to change, and backwards 
> > compatibility
> > also is an issue.
>
> I see backwards compatibility as the main issue here. There was 
> a lot of
> discussion preceding the inclusion of `guix shell', because of 
> the
> prospect of breaking existing tutorials/documentation floating 
> around on
> the internet. This is an even bigger concern for a more drastic
> reorganisation of the CLI.

I agree, I don’t think the situation can be improved without 
finding a solution to preserve BC.  But, I didn’t think it was 
worth making detailed plans for any of this before gauging whether 
the problem was one broadly considered to be worth solving.

 — Ian