Pierre wrote: >Finally, as I mentioned above with the completion systems that we have, >we've got nothing to lose in having long names.
swedebugia wrote: > Good useability is important and cryptic acronyms are not something to > expose to the user if possible to avoid IMO. > Maybe this is where we need to discuss what our target audience is? > Nerds only? […] This is a false dichotomy, in my opinion. Good usability is not at odds with using short package names. I also think that the length of package names is not going to be a deciding factor for somebody who is not a “nerd”, so let’s not go down this tangent please. There are different interfaces to package managers, and we’re currently not offering fully functional interfaces that would be more suitable for people without a “techie” background. If you want to make Guix more accessible *that’s* a screw to turn, not the length of package names. Completion should not be used as an excuse to use long package names. For one, not everyone is using Bash, so not everyone benefits from our Bash completions. (Some shells can reuse Bash completions but this does not invalidate the point.) The package name is just an identifier for command line interaction purposes. There is no reason why it should be descriptive – after all, that’s what the package description is used for. Users can easily find the package they are interested in by using the search feature. That will give them the short name by which they can refer to the package. Having that short name be long serves little purpose. In the past we agreed to certain naming rules and we put them into the contributors’ guide. If we want to change or relax those rules we need to reach consensus, collectively. This cannot be a unilateral decision. -- Ricardo
