all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pierre Neidhardt <mail@ambrevar.xyz>
To: Ricardo Wurmus <rekado@elephly.net>, swedebugia <swedebugia@riseup.net>
Cc: guix-devel@gnu.org
Subject: Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.
Date: Wed, 27 Mar 2019 17:42:04 +0100	[thread overview]
Message-ID: <878sx0xo9v.fsf@ambrevar.xyz> (raw)
In-Reply-To: <87mulg2whj.fsf@elephly.net>

[-- 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 --]

  reply	other threads:[~2019-03-27 16:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190326131842.7363.84034@vcs0.savannah.gnu.org>
     [not found] ` <20190326131845.1B177209E3@vcs0.savannah.gnu.org>
2019-03-26 14:54   ` 06/15: gnu: wesnoth-server: Rename package to the-battle-for-wesnoth-server Tobias Geerinckx-Rice
2019-03-26 14:20     ` Pierre Neidhardt
2019-03-26 15:18     ` Ricardo Wurmus
2019-03-26 15:32       ` Pierre Neidhardt
2019-03-26 17:53         ` Andreas Enge
2019-03-26 18:25           ` Pierre Neidhardt
2019-03-27 11:11           ` Ludovic Courtès
2019-03-27 11:36             ` Pierre Neidhardt
     [not found] ` <20190326131844.C73EC209E3@vcs0.savannah.gnu.org>
2019-03-27 11:07   ` 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth Ludovic Courtès
2019-03-27 11:46     ` Pierre Neidhardt
2019-03-27 13:20       ` swedebugia
2019-03-27 15:00         ` Ricardo Wurmus
2019-03-27 16:42           ` Pierre Neidhardt [this message]
2019-03-28  7:59             ` Ricardo Wurmus
2019-03-28  8:09               ` Pierre Neidhardt
2019-03-29 13:27           ` swedebugia
2019-03-27 15:15         ` Ludovic Courtès
2019-03-27 18:34         ` Tobias Geerinckx-Rice
2019-03-27 18:26           ` Pierre Neidhardt
2019-03-27 18:44             ` Daniel Jiang
2019-03-27 21:15             ` Tobias Geerinckx-Rice
2019-03-28  8:17               ` Pierre Neidhardt
2019-03-29 14:02                 ` Tobias Geerinckx-Rice
2019-03-29 15:16                   ` Andreas Enge
2019-03-29 16:42                     ` Naming, hacking, and policies Ludovic Courtès
2019-03-29 19:23                       ` Ricardo Wurmus
2019-03-31 16:33                         ` Ludovic Courtès
2019-03-30 13:54                       ` sirgazil
2019-03-31 16:37                         ` Ludovic Courtès
2019-03-31 18:03                           ` sirgazil
2019-03-31 20:31                             ` Ludovic Courtès
2019-03-31 22:59                               ` sirgazil
2019-04-01  0:07                               ` Tobias Geerinckx-Rice
2019-03-29 19:57                     ` 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth swedebugia
2019-03-27 15:13       ` Ludovic Courtès
2019-03-27 16:25         ` Pierre Neidhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878sx0xo9v.fsf@ambrevar.xyz \
    --to=mail@ambrevar.xyz \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    --cc=swedebugia@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.