Alex Kost <alez...@gmail.com> writes: > Ludovic Courtès (2016-04-19 18:52 +0300) wrote: > >> Similarly, it’s not immediately obvious to me that something like “guix >> package edit” and “guix package install” would help newcomers. >> >> On the contrary, they would likely violate the rule of least surprise: >> most other tools provide sub-commands like “install”, some provide >> “edit” and “build” as well, without further categorization. > > It's because the other tools are poor, unfeatureful and unorganized :-) > I see "guix" as a more general tool than most others: it does not > operates only on packages, it does many other things, so it should have > reasonable subgroups, and (IMO) there shouldn't be such things as "guix > install" or "guix edit".
While I agree with the categorization, I disagree on this. Like the others, I would expect there to be short aliases, at least so as not to tire users. And maybe to help newcomers, although I think it could be more beneficial to start teaching in terms of the categories, so users quickly get the underlying logic, and then just offer the aliases to reassure the users that they needn't type verbose commands all the time. As an example of the pedagogic benefit of categorizing the commands: many users coming from other package managers are confused as to what exactly "installing" a package is in Guix. It actually consists of two steps, 1. to ensure the package is in the store (by building or downloading), and 2. adding it to the user's profile. But the term "install" doesn't reflect this, and makes users think in terms of traditional package managers where installing a package means putting its files into /usr. Introducing newcomers to a command like 'guix profile add' as the primary means of adding a package to their environment, and briefly explaining the "transparently makes sure the package is in the store" part, would have them immediately learn one of the basic working principles of Guix. But maybe it's unnecessary. I still have no strong opinion. :-) Taylan