Re: Guix CLI, thoughts and suggestions

[Ian Eure <ian@retrospec.tv>]

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