guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.


From: Ricardo Wurmus
Subject: Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.
Date: Wed, 27 Mar 2019 16:00:24 +0100
User-agent: mu4e 1.0; emacs 26.1

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]