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

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

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

Pierre,

guix-commits@gnu.org wrote:
> gnu: wesnoth-server: Rename package to 
> the-battle-for-wesnoth-server.

My fault for totally missing the review window, but could we at 
least drop the articles from the-long-package-names before they 
become too widespread?  (I'll defer to you on l-abbaye, tho'.)

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Pierre,
>
> guix-commits@gnu.org wrote:
>> gnu: wesnoth-server: Rename package to 
>> the-battle-for-wesnoth-server.
>
> My fault for totally missing the review window, but could we at 
> least drop the articles from the-long-package-names before they 
> become too widespread?  (I'll defer to you on l-abbaye, tho'.)

In this case, "battle for wesnoth" sounds good too I think.

For some titles however, I think it would not make much sense to remove
the leading article, e.g. "The Witcher", "The Fall", "The Sims", etc.
(Well, none of those examples are free software.)

If we want a consistent rule, that would mean we stick to the official
names I think.  But maybe we don't need to be this consistent.

Finally, I think long names are not problematic in practice: we have
package completion from the shell, with Geiser, Emacs-Guix.el and Helm
System Packages.

Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ricardo Wurmus]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> guix-commits@gnu.org wrote:
>> gnu: wesnoth-server: Rename package to
>> the-battle-for-wesnoth-server.
>
> My fault for totally missing the review window,

These changes were not submitted as patches, so there was no review
window.

It would have been better to find consensus first.

--
Ricardo

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

Sorry, I misunderstood the conclusion of the discussion: I thought that
we would simply follow the package naming convention as per the manual.
The "article prefix" issue had not been mentioned then, this is a new issue.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Andreas Enge]

Hello,

On Tue, Mar 26, 2019 at 04:32:46PM +0100, Pierre Neidhardt wrote:
> Sorry, I misunderstood the conclusion of the discussion: I thought that
> we would simply follow the package naming convention as per the manual.

I am confused about this statement. The naming convention speaks a bit
vaguely of "project name chosen upstream"; very often, this means the
tarball name. Now there is www.wesnoth.org, which distributes tarballs and
executable files called wesnoth.*. So I would argue that the upstream
name is "wesnoth" and would suggest to revert this change.

This is in a similar spirit to "gcc" for instance; we do not call it
"gnu-compiler-collection" either, although this is the long name used
on their project web page.

Andreas

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> On Tue, Mar 26, 2019 at 04:32:46PM +0100, Pierre Neidhardt wrote:
>> Sorry, I misunderstood the conclusion of the discussion: I thought that
>> we would simply follow the package naming convention as per the manual.
>
> I am confused about this statement. The naming convention speaks a bit
> vaguely of "project name chosen upstream"; very often, this means the
> tarball name. Now there is www.wesnoth.org, which distributes tarballs and
> executable files called wesnoth.*. So I would argue that the upstream
> name is "wesnoth" and would suggest to revert this change.

I personally don't find the term "project name" vague, I think it refers
to something very specific.  In particular, in my understanding the term
"project name" was chosen to emphasize that it's not the tarball name
(or the domain name).

> This is in a similar spirit to "gcc" for instance; we do not call it
> "gnu-compiler-collection" either, although this is the long name used
> on their project web page.

Well, actually why not? :)  This would be more consistent, make more
sense and be more newbie friendly, something that acronyms never are.
("gcc" could be in the synopsis or the description.)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ludovic Courtès]

Hello,

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, Mar 26, 2019 at 04:32:46PM +0100, Pierre Neidhardt wrote:
>> Sorry, I misunderstood the conclusion of the discussion: I thought that
>> we would simply follow the package naming convention as per the manual.
>
> I am confused about this statement. The naming convention speaks a bit
> vaguely of "project name chosen upstream"; very often, this means the
> tarball name. Now there is www.wesnoth.org, which distributes tarballs and
> executable files called wesnoth.*. So I would argue that the upstream
> name is "wesnoth" and would suggest to revert this change.

+1

I agree with Ricardo that prior discussion would have been necessary.  I
think it’s now clear that this case does not fall under the
“non-controversial” category that ‘HACKING’ mentions.

Thanks,
Ludo’.

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> I agree with Ricardo that prior discussion would have been necessary.  I
> think it’s now clear that this case does not fall under the
> “non-controversial” category that ‘HACKING’ mentions.

Sorry about that, I couldn't foresee the controversy before it happened :p

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ludovic Courtès]

Hello,

guix-commits@gnu.org skribis:

> commit 375cb94130b222535ad7c7e0fa0d212483407351
> Author: Pierre Neidhardt <mail@ambrevar.xyz>
> Date:   Tue Mar 26 13:37:07 2019 +0100
>
>     gnu: wesnoth: Rename package to the-battle-for-wesnoth.

> commit c91ed484d0b66d5639ba01f9ba301ff762d9170d
> Author: Pierre Neidhardt <mail@ambrevar.xyz>
> Date:   Tue Mar 26 13:35:16 2019 +0100
>
>     gnu: abbaye: Rename package to l-abbaye-des-morts.


Apologies if I missed a previous discussion on this topic, but… I’m
skeptical about the renames.  I assume that the original names were
those commonly used in distributions, which in itself may be a good
reason to keep them.

Those names are also used upstream in some cases: the tarball for
wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
naming guidelines say (info "(guix) Package Naming"), we should try to
stick to the upstream name.

Thoughts?

Ludo’.

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Apologies if I missed a previous discussion on this topic, but… I’m
> skeptical about the renames.  I assume that the original names were
> those commonly used in distributions, which in itself may be a good
> reason to keep them.

Names may vary a lot across distributions.  Especially when it comes to
games, since they tend to have more exotic titles.

If the majority of distributions decides on a poor name, we don't have
to repeat the same mistake ;)

> Those names are also used upstream in some cases: the tarball for
> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
> naming guidelines say (info "(guix) Package Naming"), we should try to
> stick to the upstream name.
>
> Thoughts?

I think it's important to ask "why should we name a package this way."
What's the rationale behind a package name?

We are facing the users, not package maintainers.  Users are not
supposed to know about:

- domain names
- tarball names
- github names

Those are details, in my understanding, reserved to developers and
packagers.
More often than not, those shortened names are used because of technical
limitations (e.g. character length).  We don't have to forward those
limitations on ourselves.

I think it makes sense that we expose to the users names that speaks to
them, i.e. the "official project full name".

Finally, as I mentioned above with the completion systems that we have,
we've got nothing to lose in having long names.

My two cents :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[swedebugia]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> skrev: (27 mars 2019 12:46:26 CET)
>Ludovic Courtès <ludo@gnu.org> writes:
>
>> Apologies if I missed a previous discussion on this topic, but… I’m
>> skeptical about the renames.  I assume that the original names were
>> those commonly used in distributions, which in itself may be a good
>> reason to keep them.
>
>Names may vary a lot across distributions.  Especially when it comes to
>games, since they tend to have more exotic titles.
>
>If the majority of distributions decides on a poor name, we don't have
>to repeat the same mistake ;)
>
>> Those names are also used upstream in some cases: the tarball for
>> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
>> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
>> naming guidelines say (info "(guix) Package Naming"), we should try
>to
>> stick to the upstream name.
>>
>> Thoughts?
>
>I think it's important to ask "why should we name a package this way."
>What's the rationale behind a package name?
>
>We are facing the users, not package maintainers.  Users are not
>supposed to know about:
>
>- domain names
>- tarball names
>- github names
>
>Those are details, in my understanding, reserved to developers and
>packagers.
>More often than not, those shortened names are used because of
>technical
>limitations (e.g. character length).  We don't have to forward those
>limitations on ourselves.
>
>I think it makes sense that we expose to the users names that speaks to
>them, i.e. the "official project full name".
>
>Finally, as I mentioned above with the completion systems that we have,
>we've got nothing to lose in having long names.
>
>My two cents :)
>
>-- 
>Pierre Neidhardt
>https://ambrevar.xyz/

I agree with Pierre. 😃

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?
Random Joe who is new to GNU systems but dead tired of the proprietary systems he was taught in school who heard og Guix through a good friend who helps him getting started? 

Tangent to this is the focus on an  installer. Why bother with an installer if we only target nerds and educated computer professionals?

Anyone else who have opinions on the matter of acronyms in names where they can be avoided?

-- 
Sent from my k-9 mail for Android.

[-- Attachment #2: Type: text/html, Size: 3028 bytes --]

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

[Ricardo Wurmus]

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

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> 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.)

We could argue the other way around: limited interfaces should not be an
excuse for amputated names.

The Unix naming scheme ("ls" for "list", etc.) made more sense in a time
where computer users had much more limited input (no completion, etc.)
and output (small screens).

> The package name is just an identifier for command line interaction
> purposes.

I don't see it this way.  The package name is a global variable in the
Guix project, and it bears a global semantic value.  It's used as a
public identifier that has to meaningfully convey the content of the package
to the developers but also to the users.

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

Sadly the search feature is even less accessible than bash completion.
It's slower and more demanding to use.

Since this discussion got started, this hints that there might be
a "user experience" issue with our search system.

> That will give them the short name by which they can refer to the
> package.

I don't think this makes for a good user experience in my opinion.
This means that we expect everyone to be using the rather slow and
verbose "guix package --search" and not expect "the principle of least
surprise" to be working.

> Having that short name be long serves little purpose.

I can think of a some long, explicit names instead of
short, cryptic names:

- Improve search experience, completion, live-search.
- Avoid users believe existing packages are missing.
- Avoid packages re-packaging existing package because they failed to
  find them.
- Improve consistency.
- Improve code readability

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

I never claimed this ;)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

>> The package name is just an identifier for command line interaction
>> purposes.
>
> I don't see it this way.  The package name is a global variable in the
> Guix project, and it bears a global semantic value.  It's used as a
> public identifier that has to meaningfully convey the content of the package
> to the developers but also to the users.

Package names and variable names are two different things.
I disagree with the last sentence, obviously.

>> 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.
>
> Sadly the search feature is even less accessible than bash completion.
> It's slower and more demanding to use.

Let’s fix that then and make it faster.  (I think it’s pretty good
already and it’s how I find packages, not by trying out names.)

In the future, let’s please refrain from renames before a consensus has
been reached.  It would also be good to show the concrete changes on the
list before pushing them.

Thanks!

-- 
Ricardo

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Let’s fix that then and make it faster.  (I think it’s pretty good
> already and it’s how I find packages, not by trying out names.)

The user experience I'm talking about is, well, the opposite: not to try
out names.  But maybe this is hard to communicate over emails for all of us.

> In the future, let’s please refrain from renames before a consensus has
> been reached.  It would also be good to show the concrete changes on the
> list before pushing them.

Yup, it's pretty clear now that this is not a "trivial change" :p
Lesson learned!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[swedebugia]

[-- Attachment #1.1: Type: text/plain, Size: 2455 bytes --]

On 2019-03-27 16:00, Ricardo Wurmus wrote:
> 
> Pierre wrote:
>> Finally, as I mentioned above with the completion systems that we have,
>> we've got nothing to lose in having long names.

Reading the arguments of Ricardo I changed my mind and support keeping
the variable names short.

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

Thanks for sharing this. I regret having written this as a dichotomy.
I'm actually very happy with guix overall and the guix-web frontend is
awesome. :)
I'm sorry if I added tension to this discussion. I will try expressing
myself less confrontationally going forward.

> 
> 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.)

I agree.

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

I agree.

Would you agree that we try to strike a compromise with short package
variable names, synopsis' and longer descriptions? Should we state this
clearly in the documentation for packagers?

I guess a GUI-search would work like guix-web and search all three for
hits and displaying the results.

-- 
Cheers Swedebugia


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Ludovic Courtès]

Hello swedebugia,

swedebugia <swedebugia@riseup.net> skribis:

> 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?

I think you’re jumping to the conclusions here.  :-)

We didn’t discuss any acronyms, and we all agree that good usability is
important.

Ludo’.

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

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

swedebugia, Guix,

TL;DR: we're missing a field like ‘DISPLAY-NAME’, and all this is 
just hacking around the bush.

swedebugia wrote:
> Anyone else who have opinions on the matter of acronyms in names 
> where they can be avoided?

I share your aversion to acronyms and senseless abbreviation — I 
just had to type ‘extra-config’ and it made me wince — but that's 
not the point here.

> Good useability is important and cryptic acronyms are not 
> something to expose to the user if possible to avoid IMO.

You're equating your preferred naming style to usability (an 
assertion I reject) and arguing that those sceptical of the former 
oppose the latter.  This is not true.

> Maybe this is where we need to discuss what our target audience 
> is? Nerds only?
> Random Joe who is new to GNU systems but dead tired of the 
> proprietary systems he was taught in school who heard og Guix 
> through a good friend who helps him getting started?

Using this logic, I counter that these very long names unfairly 
privilege 1337 hackers who can touch-type, and hurt the average 
Jo' poking at their chiclet keyboard with a chopstick ;-)

Both arguments make about as much sense IMO (and caricature 
users).  I think a name like ‘the-battle-for-wesnoth’ helps 
*neither* user.

XLong names take longer to type on the command line, and noisy to 
read in code.  Some hinder tab-completion.  Any implication above 
that they are ‘usable’ at all is doubtful to me.

In a GUI, they still look ugly: why no spaces?  Why lowercase? 
Why bother?  We don't have to choose between POLA from other 
command-line package managers and providing pretty metadata for 
higher-level UIs.  We can do both.

…but let's find consensus first ;-)

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> TL;DR: we're missing a field like ‘DISPLAY-NAME’, and all this is 
> just hacking around the bush.

This could be a very nice idea!

> Using this logic, I counter that these very long names unfairly 
> privilege 1337 hackers who can touch-type, and hurt the average 
> Jo' poking at their chiclet keyboard with a chopstick ;-)
>
> Both arguments make about as much sense IMO (and caricature 
> users).  I think a name like ‘the-battle-for-wesnoth’ helps 
> *neither* user.

Users who cannot touch-type will typically perform simple queries, such as:

- battle wesnoth
- wesnoth battle
- battle
- wesnoth

(Using Emacs-Guix.el, Helm, or the next GTK interface.)

With "wesnoth" as a name, 3 out 4 queries won't hit a result.

I don't think that "typing" is the issue here.  At least, I wouldn't
sacrifice the _ability to search_ just to type short names.

Also an option is to alias package names.


> XLong names take longer to type on the command line, and noisy to 
> read in code.

Noisy?  Why?  Short code filled with acronyms tends to be harder to read
then long explicit names.

Package names are mostly used as inputs.  In those longs package lists,
it's really nice to have explicit names and leave little room for ambiguity.

> Some hinder tab-completion.  

Why? 

> In a GUI, they still look ugly: why no spaces?  Why lowercase? 
> Why bother?  We don't have to choose between POLA from other 
> command-line package managers and providing pretty metadata for 
> higher-level UIs.
> We can do both.

Absolutely.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Daniel Jiang]

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

Hello,

Might be related to the subject (?) but would adding something like
keywords/tags to package definitions help? On Emacs, a package definition
like this can pop up:

ack is an available package.
>
>      Status: Available from gnu -- Install
>     Archive: gnu
>     Version: 1.8
>     Summary: interface to ack-like tools
>    Homepage: https://github.com/leoliu/ack-el
>    Keywords: tools processes convenience
>

Then searching packages via keywords can be done:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Keywords.html

On Slackbuilds likewise (keywords somewhere below):
https://slackbuilds.org/repository/14.2/system/guix/

This could be metadata to help find related stuff so there can be a games
tag for the wesnoth package. Also dunno how related, but in Common Lisp
nicknames can be defined for packages. I wrote some game programming
libraries bindings before that uses a longer name for the definition but a
two letter nickname to make it easier to use in practice.

Sincerely,
Daniel Jiang

On Wed, Mar 27, 2019 at 1:26 PM Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>
> > TL;DR: we're missing a field like ‘DISPLAY-NAME’, and all this is
> > just hacking around the bush.
>
> This could be a very nice idea!
>
> > Using this logic, I counter that these very long names unfairly
> > privilege 1337 hackers who can touch-type, and hurt the average
> > Jo' poking at their chiclet keyboard with a chopstick ;-)
> >
> > Both arguments make about as much sense IMO (and caricature
> > users).  I think a name like ‘the-battle-for-wesnoth’ helps
> > *neither* user.
>
> Users who cannot touch-type will typically perform simple queries, such as:
>
> - battle wesnoth
> - wesnoth battle
> - battle
> - wesnoth
>
> (Using Emacs-Guix.el, Helm, or the next GTK interface.)
>
> With "wesnoth" as a name, 3 out 4 queries won't hit a result.
>
> I don't think that "typing" is the issue here.  At least, I wouldn't
> sacrifice the _ability to search_ just to type short names.
>
> Also an option is to alias package names.
>
>
> > XLong names take longer to type on the command line, and noisy to
> > read in code.
>
> Noisy?  Why?  Short code filled with acronyms tends to be harder to read
> then long explicit names.
>
> Package names are mostly used as inputs.  In those longs package lists,
> it's really nice to have explicit names and leave little room for
> ambiguity.
>
> > Some hinder tab-completion.
>
> Why?
>
> > In a GUI, they still look ugly: why no spaces?  Why lowercase?
> > Why bother?  We don't have to choose between POLA from other
> > command-line package managers and providing pretty metadata for
> > higher-level UIs.
> > We can do both.
>
> Absolutely.
>
> --
> Pierre Neidhardt
> https://ambrevar.xyz/
>

[-- Attachment #2: Type: text/html, Size: 4063 bytes --]

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

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Pierre, hell, all,

Pierre Neidhardt wrote:
> (Using Emacs-Guix.el, Helm, or the next GTK interface.)

Emacs?  Helm?  This ‘average user’ thing is a red herring.

I visited my mother today and she asked why my screen is always 
black and white.

I admit to being irritated by this speculation in my previous 
reply, yet happily joined in, and I shouldn't have.  Since…

>> Why bother?  We don't have to choose between POLA from other 
>> command-line package managers and providing pretty metadata for 
>> higher-level UIs.
>> We can do both.
>
> Absolutely.

…this is all that matters.

(No, not people agreeing with me.)

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> I admit to being irritated by this speculation in my previous 
> reply, yet happily joined in, and I shouldn't have.  Since…

Indeed, I felt a tense tone overall in this discussion.  Sorry if I'm to
blame here, not at all intended.

Let's relax keep it friendly then! :) we are all having an interesting
discussion and everyone brought up very good arguments.

And if anyone brings up an irritating speculation, it's probably not
meant to be offensive ;)  Sometimes we don't phrase as well as we should
be, all we need is to clarify.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

Hi Pierre!

> Let's relax keep it friendly then! :) we are all having an 
> interesting
> discussion and everyone brought up very good arguments.

Oh, I was annoyed by the luser/nerd dichotomy that's rampant 
everywhere, not just (perhaps least of all) in Guix, not by any 
person here!  :-)

I still think this change should be reverted, but that's not at 
all intended to be unfriendly.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Andreas Enge]

On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote:
> I still think this change should be reverted

I also think so.

The wording in the naming guidelines is intentionally a bit vague;
the intention was definitely to take in general the tarball name, or maybe
if this does not fit the domain name or something "similarly canonical".
The tarball name does not always work, for instance in cases where it is
"v0.15.zip". So we cannot have a strict rule, but the idea was to take the
"canonical short name". When writing the section, I did not expect this
part to lead to controversies; the real question was how to handle special
characters (lowercase, replace underscores with dashes), and what to do
for (at the time) python packages.

I am happy to make the wording clearer. But I am not sure whether replacing
"project name" by "package name" makes a difference. What is a "package"?
But if you think it is better, why not.

We could also add "short" in front of "projet"/"package name", and maybe
add that this usually corresponds to something like the base name of the
tarball, the git repository name or the domain where the project is hosted.

What do you think?

Andreas

Naming, hacking, and policies

[Ludovic Courtès]

Hello,

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote:
>> I still think this change should be reverted
>
> I also think so.

I’d also be in favor of reverting.

I mean perhaps some of the renames may be less controversial than
others, but it looks like we started on the wrong foot.  I’d be in favor
of renaming at least so we can discuss things calmly, even if the
outcome were to reinstate some of these changes.

Thoughts?

A couple of things come to my mind:

  • Fundamentally, this is a very minor issue.  Each one of us should
    try hard not to spend more energy on it than on, say, testing the
    installer.  :-)

  • The problem at hand is more of a policy and working-together issue
    than a UI issue or anything like that: What’s a “trivial” change?
    What can be considered controversial?  What do we do when a
    controversial change goes in?  How do we take into account previous
    discussions (after all, these packages were very likely reviewed
    here in the first place)?  How do we adjust our documented practices
    to reflect this?  Etc.

So I think that Andreas’ proposal to clarify the naming guidelines is
the right attitude here.  Let’s take this opportunity to share and
refine our understanding of the issue, and to write it down.

Regarding the “controversial” bit, I think naming is almost always
controversial.  :-)  In other cases, by participating in the project, I
think we all have a good idea of what’s going to generate heated
discussions.  Sometimes we get that wrong, and that’s fine.  In this
case, I’d suggest that the right approach is to revert the change so
that discussion can take place without pressure.  What about adding this
to ‘HACKING’?

As for taking previous discussions into account, it’s not always easy to
do because words can get lost.  However, it’s generally a good thing to
assume that changing something that has previously passed review may
require discussion.

Thoughts?

> I am happy to make the wording clearer. But I am not sure whether replacing
> "project name" by "package name" makes a difference. What is a "package"?
> But if you think it is better, why not.
>
> We could also add "short" in front of "projet"/"package name", and maybe
> add that this usually corresponds to something like the base name of the
> tarball, the git repository name or the domain where the project is hosted.

Packages usually have a “system name” (that’s the terminology used on
Savannah) and a “pretty name”, like ‘guix’ and ‘GNU Guix’.  I believe
the intent of those guidelines was to suggest keeping the system name,
not the fancy name.  Perhaps this is what should be clarified?

Thanks,
Ludo’.

Re: Naming, hacking, and policies

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Andreas Enge <andreas@enge.fr> skribis:
>
>> On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote:
>>> I still think this change should be reverted
>>
>> I also think so.
>
> I’d also be in favor of reverting.

I’m also in favour.  A pure revert would not be enough, though, would
it?  The new names would need to remain as deprecated names (I know of
at least one person who installed some of these games under the long
names).

--
Ricardo

Re: Naming, hacking, and policies

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Andreas Enge <andreas@enge.fr> skribis:
>>
>>> On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote:
>>>> I still think this change should be reverted
>>>
>>> I also think so.
>>
>> I’d also be in favor of reverting.
>
> I’m also in favour.  A pure revert would not be enough, though, would
> it?  The new names would need to remain as deprecated names (I know of
> at least one person who installed some of these games under the long
> names).

Indeed.  So I reverted one in commit
e23f2ff1836e982fc2289093aab0994e0c0cf2d2 (this particular rename broke a
unit test.)  As you can see in this commit, it’s mostly a matter of
swapping the package names between the deprecated and the non-deprecated
variant.

Any takers?  Thoughts?

Thanks,
Ludo’.

Re: Naming, hacking, and policies

[sirgazil]

El 29/03/19 a las 11:42 a. m., Ludovic Courtès escribió:

[...]


> Packages usually have a “system name” (that’s the terminology used on
> Savannah) and a “pretty name”, like ‘guix’ and ‘GNU Guix’.  I believe
> the intent of those guidelines was to suggest keeping the system name,
> not the fancy name.  Perhaps this is what should be clarified?
> 
> Thanks,
> Ludo’.

A comment on the accessibility of names:

Last time I tried browsing packages in a GTK+ application on Debian 
using a screen reader, I didn't like the experience. The screen reader 
read in Spanish (my system language) all the names of the packages, most 
of them in "system name" format and made of English words. No good. 
Also, if I recall correctly, the screen reader didn't read initialisms 
correctly.

I bet there are things to improve in screen readers, accessibility of 
GUI toolkits, and package definitions. At that time, for example, Orca 
could not read multilingual HTML documents that used explicitly the LANG 
attribute in elements. I don't know if GTK+ offers something similar to 
the HTML LANG attribute for GUI components. Package definitions I've 
seen don't indicate in which language a package name is written so that 
a screen reader could switch its voice if necessary, nor they provide a 
way to know if a package name is an initialism, so that the screen 
reader can read it as such.

I don't know exactly what should be done in Guix, though, but I think 
having a "system name" and a "pretty name" that is translatable could 
help a little bit.

I hope libre screen readers get so smart they will figure all these 
things by themselves :)


My 2¢


-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: Naming, hacking, and policies

[Ludovic Courtès]

Hi sirgazil,

sirgazil <sirgazil@zoho.com> skribis:

> I don't know exactly what should be done in Guix, though, but I think
> having a "system name" and a "pretty name" that is translatable could
> help a little bit.

It’s a tricky topic indeed (and not specific to Guix).

There are i18n and accessibility (a11n) issues, I agree.  The problem is
that those “system names” are essentially identifiers, pretty much like
Unix command names.  Sometimes they’re abbreviations of common English
names, sometimes they’re proper names, etc.  So not all of them are
subject to translation.  I think they should really be treated like
identifiers in programming languages or command names.

Now, having synopses and descriptions that are actual text subject to
translation certainly helps.  Maybe we could do better, but I wouldn’t
know how!

Thanks,
Ludo’.

Re: Naming, hacking, and policies

[sirgazil]

El 31/03/19 a las 11:37 a. m., Ludovic Courtès escribió:
> Hi sirgazil,
> 
> sirgazil <sirgazil@zoho.com> skribis:
> 
>> I don't know exactly what should be done in Guix, though, but I think
>> having a "system name" and a "pretty name" that is translatable could
>> help a little bit.
> 
> It’s a tricky topic indeed (and not specific to Guix).
> 
> There are i18n and accessibility (a11n) issues, I agree.  The problem is
> that those “system names” are essentially identifiers, pretty much like
> Unix command names.  Sometimes they’re abbreviations of common English
> names, sometimes they’re proper names, etc.  So not all of them are
> subject to translation.  I think they should really be treated like
> identifiers in programming languages or command names.


Oh yeah, I'm not suggesting to translate "system names", but have both 
"system names" and "pretty names", and only the latter would be 
internationalized :)


> Now, having synopses and descriptions that are actual text subject to
> translation certainly helps.  Maybe we could do better, but I wouldn’t
> know how!
> 
> Thanks,
> Ludo’.
> 

-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: Naming, hacking, and policies

[Ludovic Courtès]

sirgazil <sirgazil@zoho.com> skribis:

> El 31/03/19 a las 11:37 a. m., Ludovic Courtès escribió:
>> Hi sirgazil,
>>
>> sirgazil <sirgazil@zoho.com> skribis:
>>
>>> I don't know exactly what should be done in Guix, though, but I think
>>> having a "system name" and a "pretty name" that is translatable could
>>> help a little bit.
>>
>> It’s a tricky topic indeed (and not specific to Guix).
>>
>> There are i18n and accessibility (a11n) issues, I agree.  The problem is
>> that those “system names” are essentially identifiers, pretty much like
>> Unix command names.  Sometimes they’re abbreviations of common English
>> names, sometimes they’re proper names, etc.  So not all of them are
>> subject to translation.  I think they should really be treated like
>> identifiers in programming languages or command names.
>
>
> Oh yeah, I'm not suggesting to translate "system names", but have both
> "system names" and "pretty names", and only the latter would be
> internationalized :)

But even that is not really feasible: often there’s no “pretty name”,
sometimes there’s one that’s not translatable (“GNU grep”?  “Scribus”?).

Ludo’.

Re: Naming, hacking, and policies

[sirgazil]

El 31/03/19 a las 3:31 p. m., Ludovic Courtès escribió:
> sirgazil <sirgazil@zoho.com> skribis:
> 
>> El 31/03/19 a las 11:37 a. m., Ludovic Courtès escribió:
>>> Hi sirgazil,
>>>
>>> sirgazil <sirgazil@zoho.com> skribis:
>>>
>>>> I don't know exactly what should be done in Guix, though, but I think
>>>> having a "system name" and a "pretty name" that is translatable could
>>>> help a little bit.
>>>
>>> It’s a tricky topic indeed (and not specific to Guix).
>>>
>>> There are i18n and accessibility (a11n) issues, I agree.  The problem is
>>> that those “system names” are essentially identifiers, pretty much like
>>> Unix command names.  Sometimes they’re abbreviations of common English
>>> names, sometimes they’re proper names, etc.  So not all of them are
>>> subject to translation.  I think they should really be treated like
>>> identifiers in programming languages or command names.
>>
>>
>> Oh yeah, I'm not suggesting to translate "system names", but have both
>> "system names" and "pretty names", and only the latter would be
>> internationalized :)
> 
> But even that is not really feasible: often there’s no “pretty name”,
> sometimes there’s one that’s not translatable (“GNU grep”?  “Scribus”?).


Hmm, true.

-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.io/

Re: Naming, hacking, and policies

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

Ludo',

Ludovic Courtès wrote:
> sirgazil <sirgazil@zoho.com> skribis:
>> Oh yeah, I'm not suggesting to translate "system names", but 
>> have both
>> "system names" and "pretty names", and only the latter would be
>> internationalized :)
>
> But even that is not really feasible: often there’s no “pretty 
> name”,
> sometimes there’s one that’s not translatable (“GNU grep”? 
> “Scribus”?).

Translation doesn't *mandate* mangling.  The French name for GNU 
grep is presumably just GNU grep, not la greppe GNU.

And if an upstream name isn't ‘pretty’ (which is why I don't like 
this subjective term and prefer DISPLAY-NAME or what even ever), 
we can just omit it & display its NAME everywhere, no?

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[swedebugia]

[-- Attachment #1.1: Type: text/plain, Size: 1692 bytes --]

On 2019-03-29 16:16, Andreas Enge wrote:
> On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote:
>> I still think this change should be reverted
> 
> I also think so.

Agreed, I remember having proposed and gotten a 1 name change through
the patch-review-process and that worked fine and that I had to
deprecate the old name properly to get it accepted.

Pierre would you be willing to prepare some patches to include the long
names/project names in the descriptions instead and send them to the
patches-list?

> 
> The wording in the naming guidelines is intentionally a bit vague;
> the intention was definitely to take in general the tarball name, or maybe
> if this does not fit the domain name or something "similarly canonical".
> The tarball name does not always work, for instance in cases where it is
> "v0.15.zip". So we cannot have a strict rule, but the idea was to take the
> "canonical short name". When writing the section, I did not expect this
> part to lead to controversies; the real question was how to handle special
> characters (lowercase, replace underscores with dashes), and what to do
> for (at the time) python packages.
> 
> I am happy to make the wording clearer. But I am not sure whether replacing
> "project name" by "package name" makes a difference. What is a "package"?
> But if you think it is better, why not.
> 
> We could also add "short" in front of "projet"/"package name", and maybe
> add that this usually corresponds to something like the base name of the
> tarball, the git repository name or the domain where the project is hosted.
> 
> What do you think?

👍


-- 
Cheers Swedebugia


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Ludovic Courtès]

Hi!

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Apologies if I missed a previous discussion on this topic, but… I’m
>> skeptical about the renames.  I assume that the original names were
>> those commonly used in distributions, which in itself may be a good
>> reason to keep them.
>
> Names may vary a lot across distributions.  Especially when it comes to
> games, since they tend to have more exotic titles.
>
> If the majority of distributions decides on a poor name, we don't have
> to repeat the same mistake ;)

I agree, but there’s also a tension between that and not violating the
“principle of least surprise”.  Sometimes the latter outweighs the
former.

>> Those names are also used upstream in some cases: the tarball for
>> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
>> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
>> naming guidelines say (info "(guix) Package Naming"), we should try to
>> stick to the upstream name.
>>
>> Thoughts?
>
> I think it's important to ask "why should we name a package this way."
> What's the rationale behind a package name?

I agree with what you’re saying but (1) we’re talking about package
name, which are different from fully spelled out “fancy names” (like
“L’Abbaye des morts”).

For package names, our policy is to follow upstream’s own package name.
For The Battle of Westnoth, it’s “westnoth”.

By doing that, we make the user’s lives easier in that they may already
be familiar with this short name.  If, instead, we try to roll our own
that neither distros nor upstream uses, then we’re not helping people.

Completion helps, I agree, but not everyone uses Helm either.  If you’re
in Bash and type “guix package -i w<TAB>” and don’t see “westnoth”,
you’re unhappy, and user unhappiness is bad.  :-)

In a GUI things may be different because the package name doesn’t matter
that much.

Thanks,
Ludo’.

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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 3923 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> If the majority of distributions decides on a poor name, we don't have
>> to repeat the same mistake ;)
>
> I agree, but there’s also a tension between that and not violating the
> “principle of least surprise”.  Sometimes the latter outweighs the
> former.

I agree and I'm pro the principle of least surprise.  I believe the full
package names do go in that direction.

>>> Those names are also used upstream in some cases: the tarball for
>>> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub
>>> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’).  Like our
>>> naming guidelines say (info "(guix) Package Naming"), we should try to
>>> stick to the upstream name.
>>>
>>> Thoughts?
>>
>> I think it's important to ask "why should we name a package this way."
>> What's the rationale behind a package name?
>
> I agree with what you’re saying but (1) we’re talking about package
> name, which are different from fully spelled out “fancy names” (like
> “L’Abbaye des morts”).
>
> For package names, our policy is to follow upstream’s own package name.
> For The Battle of Westnoth, it’s “westnoth”.

Our  current policy is to follow upstream _project names_, which is often
different from the package name.

From the manual:

--8<---------------cut here---------------start------------->8---
   Both are usually the same and correspond to the lowercase conversion
of the project name chosen upstream, with underscores replaced with
hyphens.  For instance, GNUnet is available as ‘gnunet’, and SDL_net as
‘sdl-net’.
--8<---------------cut here---------------end--------------->8---

If you want to follow upstream _package_ names, then we should fix the
manual I think.

> By doing that, we make the user’s lives easier in that they may already
> be familiar with this short name.  If, instead, we try to roll our own
> that neither distros nor upstream uses, then we’re not helping people.

Isn't it the other way around?

I think that we would be rolling our own package name by using short names.

Using the official full project name is an attempt to prevent the
spreading of self-rolled names, in my opinion.

> Completion helps, I agree, but not everyone uses Helm either.  If you’re
> in Bash and type “guix package -i w<TAB>” and don’t see “westnoth”,
> you’re unhappy, and user unhappiness is bad.  :-)

But that's true the other way around too: A user could expect
"battle-for-wesnoth" and with

  guix package -i b<TAB>

and be disappointed.

I believe there is a confusion around orthogonal problems:

- Naming: it's about identifying package objects.  This is at the
  semantic level, nothing practical here.  This is user facing.

- Search / completion interface (bash completion and the like).  The
  problem is with Bash, not with names.  Bash completion equally fails
  at completing short names if the prefix is wrong (sl bring up a steam
  locomotive on some systems :p).  This is true for all sort of
  "prefix-based" completion systems.

We have ungoogled-chromium after all, not something many people on the planet
would expect!  :p
But I like it and I think it's a good name :)

> In a GUI things may be different because the package name doesn’t matter
> that much.

Bash completion is a UI ;)

The reason this whole thread started is because the original poster
failed to find some games among our package because of arguably not so
trivial names.  It has happened before that a package got packaged twice
because of different naming.  I believe we should strive at removing any
ambiguity in package names.

Our package names have the status of global
variables: they are the names which, I think, matter the most.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]