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