Hi Carlo,
Thank you for the thoughtful reply.
Carlo Zancanaro <ca...@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