Opposition to new single-letter package name "t"

Opposition to new single-letter package name "t"

[Mark H Weaver]

Hello Guix,

Yesterday, an obscure package called "t" was added to Guix.  We should
reject such short package names in Guix unless there's a very compelling
reason to keep them.

The problem with single-letter package names is that the probability of
collisions is far too high.  Due to the so-called "birthday paradox", it
only takes 5 such package names before the probability of a collision
gets close to 50%.  Given this, it's an act of extraordinary hubris to
claim a single-letter name for one's package.

We've already had at least one collision involving 2-letter names.  It
takes 26 such names before the probability of collision reaches ~50%.  A
few years ago, someone wrote a tool based on Guile for "programmatic
computer-aided design" and called it "Ao".  It turns out that name is
already taken by a cross platform audio library which is in Guix.

We have precedent for renaming single-letter package names in Guix.  We
have already changed "s" to "s-shell", and "v" to "vlang".  Let's choose
a longer name for "t".  Here's the package definition:

--8<---------------cut here---------------start------------->8---
(define-public t
  ;; Last release is more than 10 years old.  Using latest commit.
  (let ((changeset "89ad444c000b")
        (revision "97"))
    (package
      (name "t")
      (version (git-version "1.2.0" revision changeset))
      (source
       (origin
         (method hg-fetch)
         (uri (hg-reference
               (url "https://hg.stevelosh.com/t")
               (changeset changeset)))
         (file-name (string-append name "-" version "-checkout"))
         (sha256
          (base32 "0c8zn7l0xq65wp07h7mxnb5ww56d1443l2vkjvx5sj6wpcchfn0s"))))
      (build-system python-build-system)
      (native-inputs
       `(("python-cram" ,python-cram)))
      (synopsis "Command-line todo list manager")
      (description
       "@command{t} is a command-line todo list manager for people that want
to finish tasks, not organize them.")
      (home-page "https://stevelosh.com/projects/t/")
      (license license:expat))))
--8<---------------cut here---------------end--------------->8---

Any suggestions for a longer name?  Maybe "t-organizer" or
"t-todo-list-manager"?

Note that I'm not proposing to change the name of the executable, since
that only affects users who have chosen to install the package, and
naturally such users will want to minimize their typing when using the
program.  I merely propose to change the Scheme variable name and the
'name' field of the package.

Thoughts?

     Regards,
       Mark

Re: Opposition to new single-letter package name "t"

[Raghav Gururajan]

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

Hi Mark!

> Yesterday, an obscure package called "t" was added to Guix.  We should
> reject such short package names in Guix unless there's a very compelling
> reason to keep them.
> 
> The problem with single-letter package names is that the probability of
> collisions is far too high.  Due to the so-called "birthday paradox", it
> only takes 5 such package names before the probability of a collision
> gets close to 50%.  Given this, it's an act of extraordinary hubris to
> claim a single-letter name for one's package.
> 
> We've already had at least one collision involving 2-letter names.  It
> takes 26 such names before the probability of collision reaches ~50%.  A
> few years ago, someone wrote a tool based on Guile for "programmatic
> computer-aided design" and called it "Ao".  It turns out that name is
> already taken by a cross platform audio library which is in Guix.
> 
> We have precedent for renaming single-letter package names in Guix.  We
> have already changed "s" to "s-shell", and "v" to "vlang".  Let's choose
> a longer name for "t".  Here's the package definition:

Makes complete sense. Thanks for bringing it to our attention. :-)

> Any suggestions for a longer name?  Maybe "t-organizer" or
> "t-todo-list-manager"?

How about t-cli?

@Jorge WDYT?

Regards,
RG.


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

Re: Opposition to new single-letter package name "t"

[jgart]

Hi Everyone!

> Maybe "t-organizer" or "t-todo-list-manager"?

I like Mark's suggestion of "t-todo-list-manager" as well as Raghav's suggestion for "t-cli"; in that order.

Either name sounds good to me, though.

best regards,

jgart

libremiami.org
search.libremiami.org


March 9, 2021 12:39 AM, "Raghav Gururajan" <rg@raghavgururajan.name> wrote:

> Hi Mark!
> 
>> Yesterday, an obscure package called "t" was added to Guix. We should
>> reject such short package names in Guix unless there's a very compelling
>> reason to keep them.
>> 
>> The problem with single-letter package names is that the probability of
>> collisions is far too high. Due to the so-called "birthday paradox", it
>> only takes 5 such package names before the probability of a collision
>> gets close to 50%. Given this, it's an act of extraordinary hubris to
>> claim a single-letter name for one's package.
>> 
>> We've already had at least one collision involving 2-letter names. It
>> takes 26 such names before the probability of collision reaches ~50%. A
>> few years ago, someone wrote a tool based on Guile for "programmatic
>> computer-aided design" and called it "Ao". It turns out that name is
>> already taken by a cross platform audio library which is in Guix.
>> 
>> We have precedent for renaming single-letter package names in Guix. We
>> have already changed "s" to "s-shell", and "v" to "vlang". Let's choose
>> a longer name for "t". Here's the package definition:
> 
> Makes complete sense. Thanks for bringing it to our attention. :-)
> 
>> Any suggestions for a longer name? Maybe "t-organizer" or
>> "t-todo-list-manager"?
> 
> How about t-cli?
> 
> @Jorge WDYT?
> 
> Regards,
> RG.

Re: Opposition to new single-letter package name "t"

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 337 bytes --]

> I like Mark's suggestion of "t-todo-list-manager" as well as Raghav's suggestion for "t-cli"; in that order.
> 
> Either name sounds good to me, though.

Cool!

Since, we already mention "todo list manager" in description, I think 
"ti-cli" is better.

@Nicolas

Could you merge the attached patch please?

Regards,
RG.

[-- Attachment #1.1.2: 0001-gnu-Rename-t-to-t-cli.patch --]
[-- Type: text/x-patch, Size: 1017 bytes --]

From 0b3f82c8c8b0685583e99b6c3e48e1f0c22a7706 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan <rg@raghavgururajan.name>
Date: Tue, 9 Mar 2021 01:03:32 -0500
Subject: [PATCH] gnu: Rename "t" to "t-cli".

* gnu/packages/task-management.scm (t): Rename to t-cli.
---
 gnu/packages/task-management.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/task-management.scm b/gnu/packages/task-management.scm
index 9667df6030..dfad07b32b 100644
--- a/gnu/packages/task-management.scm
+++ b/gnu/packages/task-management.scm
@@ -44,12 +44,12 @@
   #:use-module (guix build-system meson)
   #:use-module (guix build-system python))
 
-(define-public t
+(define-public t-cli
   ;; Last release is more than 10 years old.  Using latest commit.
   (let ((changeset "89ad444c000b")
         (revision "97"))
     (package
-      (name "t")
+      (name "t-cli")
       (version (git-version "1.2.0" revision changeset))
       (source
        (origin
-- 
2.30.1


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

Re: Opposition to new single-letter package name "t"

[Leo Prikler]

Am Dienstag, den 09.03.2021, 01:08 -0500 schrieb Raghav Gururajan:
> > I like Mark's suggestion of "t-todo-list-manager" as well as
> > Raghav's suggestion for "t-cli"; in that order.
> > 
> > Either name sounds good to me, though.
> 
> Cool!
> 
> Since, we already mention "todo list manager" in description, I
> think 
> "ti-cli" is better.
I personally disagree.  Let's assume we do have a collision and the
other program also happens to be a CLI – then we're back to square one.
Also, assuming it is a GUI instead of a CLI and the package can be
named "t-gui", there will be the implication that the two are related
when they need not be.

On a related note, the description treads awfully close to advertising
territory.

I'd say "t-todo-list-manager", perhaps shortened to "t-todos". 
Alternatively, we might borrow some bits from the go-build-system
convention and name it com-stevelosh-t.

Regards,
Leo

Re: Opposition to new single-letter package name "t"

[Tobias Geerinckx-Rice]

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

Raghav Gururajan 写道：
> Since, we already mention "todo list manager" in description, I 
> think 
> "ti-cli" is better.

It says nothing about the package and does not uniquely identify 
it:

  bundlerApp {
    pname = "t";
    [...]

    meta = with lib; {
      description = "A command-line power tool for Twitter";
      homepage    = "http://sferik.github.io/t/";
      [...]
    };
  }

It's “t”!  It's “CLI”!  It's... a totally different package[0]!

Please: t-todo-manager (t-todo-whatever, I don't care) or 
$something_a_mainstream_distro_uses, but not yet another 
bikeshedded unique name, fun as they are to do.

Kind regards,

T G-R

[0]: 
https://github.com/NixOS/nixpkgs/blob/release-20.09/pkgs/tools/misc/t/default.nix

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

Re: Opposition to new single-letter package name "t"

[Julien Lepiller]

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

Well, python-t should be unique, right? There can't be a collision on pypi. Well, except if that package is not on pypi?

Le 9 mars 2021 06:38:04 GMT-05:00, Tobias Geerinckx-Rice <me@tobias.gr> a écrit :
>Raghav Gururajan 写道：
>> Since, we already mention "todo list manager" in description, I 
>> think 
>> "ti-cli" is better.
>
>It says nothing about the package and does not uniquely identify 
>it:
>
>  bundlerApp {
>    pname = "t";
>    [...]
>
>    meta = with lib; {
>      description = "A command-line power tool for Twitter";
>      homepage    = "http://sferik.github.io/t/";
>      [...]
>    };
>  }
>
>It's “t”!  It's “CLI”!  It's... a totally different package[0]!
>
>Please: t-todo-manager (t-todo-whatever, I don't care) or 
>$something_a_mainstream_distro_uses, but not yet another 
>bikeshedded unique name, fun as they are to do.
>
>Kind regards,
>
>T G-R
>
>[0]: 
>https://github.com/NixOS/nixpkgs/blob/release-20.09/pkgs/tools/misc/t/default.nix

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

Re: Opposition to new single-letter package name "t"

[Ricardo Wurmus]

Julien Lepiller <julien@lepiller.eu> writes:

> Well, python-t should be unique, right? There can't be a collision on pypi. Well, except if that package is not on pypi?

Since it’s not a library we shouldn’t name it “python-<anything>”.

I agree with Tobias and others who suggested “t-todo-manager” or
similar; not “t-cli”, please.

-- 
Ricardo

Re: Opposition to new single-letter package name "t"

[Raghav Gururajan]

[-- Attachment #1.1.1: Type: text/plain, Size: 248 bytes --]

Hi Tobias!

> Please: t-todo-manager (t-todo-whatever, I don't care) or 
> $something_a_mainstream_distro_uses, but not yet another bikeshedded 
> unique name, fun as they are to do.

Makes sense. I have attached the patch.

Regards,
RG.

[-- Attachment #1.1.2: 0001-gnu-Rename-t-to-t-todo-manager.patch --]
[-- Type: text/x-patch, Size: 1053 bytes --]

From 04066b34518fc01290f12093910387e10c04fa08 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan <rg@raghavgururajan.name>
Date: Tue, 9 Mar 2021 07:37:28 -0500
Subject: [PATCH] gnu: Rename "t" to "t-todo-manager".

* gnu/packages/task-management.scm (t): Rename to t-todo-manager.
---
 gnu/packages/task-management.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/task-management.scm b/gnu/packages/task-management.scm
index 9667df6030..3edf01a9f5 100644
--- a/gnu/packages/task-management.scm
+++ b/gnu/packages/task-management.scm
@@ -44,12 +44,12 @@
   #:use-module (guix build-system meson)
   #:use-module (guix build-system python))
 
-(define-public t
+(define-public t-todo-manager
   ;; Last release is more than 10 years old.  Using latest commit.
   (let ((changeset "89ad444c000b")
         (revision "97"))
     (package
-      (name "t")
+      (name "t-todo-manager")
       (version (git-version "1.2.0" revision changeset))
       (source
        (origin
-- 
2.30.1


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

Re: Opposition to new single-letter package name "t"

[Nicolas Goaziou]

Hello,

Raghav Gururajan <rg@raghavgururajan.name> writes:

> Makes sense. I have attached the patch.

Applied. Thank you.

Sorry for the mess!

Regards,
-- 
Nicolas Goaziou

Re: Opposition to new single-letter package name "t"

[Mark H Weaver]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Raghav Gururajan <rg@raghavgururajan.name> writes:
>
>> Makes sense. I have attached the patch.
>
> Applied. Thank you.
>
> Sorry for the mess!

No worries, it's no mess at all.  Thanks to Nicolas and Raghav for
taking care of renaming it, and also to everyone who contributed to the
bike-shed discussion :)

       Mark

Search improvements (Was: Opposition to new single-letter package name "t")

[Taylan Kammer]

On 09.03.2021 12:38, Tobias Geerinckx-Rice wrote:
> Raghav Gururajan 写道：
>> Since, we already mention "todo list manager" in description, I think
>> "ti-cli" is better.
> 
> It says nothing about the package and does not uniquely identify it:
> 
>  bundlerApp {
>    pname = "t";
>    [...]
> 
>    meta = with lib; {
>      description = "A command-line power tool for Twitter";
>      homepage    = "http://sferik.github.io/t/";
>      [...]
>    };
>  }
> 
> It's “t”!  It's “CLI”!  It's... a totally different package[0]!
> 
> Please: t-todo-manager (t-todo-whatever, I don't care) or
> $something_a_mainstream_distro_uses, but not yet another bikeshedded
> unique name, fun as they are to do.
> 
> Kind regards,
> 
> T G-R
> 
> [0]:
> https://github.com/NixOS/nixpkgs/blob/release-20.09/pkgs/tools/misc/t/default.nix
> 

I agree that t-todo-manager is the superior choice.  (With a secondary
preference for "t-todo-list-manager".)

This discussion made me realize that "guix search" might benefit from
the following improvement though:  I think the relevance score for a
search result should be increased significantly if the searched word is
a standalone (not substring) part of a package's name when the name is
split into dash-separated words.

For instance, the package "emacs-hl-todo" should get a much higher score
than "emacs-mastodon" when searching for "todo".  Currently the Mastodon
one has score 11 and the todo one only 9.

The same thing goes for the synopsis and description of the package, but
with respectively lower increases to the score.  (I.e. name > synopsis >
description.)

Handling of plurals like "todos" instead of "todo" would also be great
but could be left to a later step.

Any thoughts about / objections to this idea?  To be honest I haven't
checked if there's maybe already a bug report about this.


- Taylan

Re: Search improvements (Was: Opposition to new single-letter package name "t")

[zimoun]

Hi,

On Tue, 9 Mar 2021 at 14:37, Taylan Kammer <taylan.kammer@gmail.com> wrote:

> This discussion made me realize that "guix search" might benefit from
> the following improvement though:  I think the relevance score for a
> search result should be increased significantly if the searched word is
> a standalone (not substring) part of a package's name when the name is
> split into dash-separated words.

Currently, perfect match uses the weight of 5 and substring match uses
1.  You are proposing to add something between, say 3, for perfect
match on substring delimited by dash.  Why not.

> For instance, the package "emacs-hl-todo" should get a much higher score
> than "emacs-mastodon" when searching for "todo".  Currently the Mastodon
> one has score 11 and the todo one only 9.

Here how the relevance score reads:

query: todo
| field       |  emacs-hl-todo |  emacs-mastodon | weight |
|-------------+----------------+-----------------+--------|
| name        |              1 |               1 |      4 |
| synopsis    |              1 |               1 |      3 |
| description |              1 |               2 |      2 |
|-------------+----------------+-----------------+--------|
| total       | 1*4+1*3+2*1= 9 | 1*4+1*3+2*2= 11 |        |

Therefore, something looks wrong here: the score for emacs-hl-todo
should be 1*4+1*5*3+1*5*2= 29 because the term TODO should be
considered as a perfect match for the query todo.


> The same thing goes for the synopsis and description of the package, but
> with respectively lower increases to the score.  (I.e. name > synopsis >
> description.)

Your proposal just needs the tweak of 'score' in the function
'relevance' from (guix ui).  The weight for the field is another part
(see %package-metrics in (guix ui))


> Handling of plurals like "todos" instead of "todo" would also be great
> but could be left to a later step.

The issue with this is that it is strongly connected to the language.
Therefore, an external library implementing Natural Language should be
added.  And I am not convinced it is worth at the CLI level.


> Any thoughts about / objections to this idea?  To be honest I haven't
> checked if there's maybe already a bug report about this.

If you are interested, there is such discussion in this heavy thread:

<http://issues.guix.gnu.org/issue/39258>

And the 'relevance' function could be improved, for sure.  For
example, I proposed TF-IDF here:

<https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00252.html>

and I did some tiny math calculs (optimization) to compute "better"
relevance weight (%package-metrics) but the current choice are not so
bad and simple enough. :-)

Previous week, I have started to examine a strategy based on
Bag-Of-Word and some word embedings strategies; mimicking a simple
autoencoder [1] such as Word2Vec [2] but since the Guile tools are
poor in this field, I have started to use Julia first to look if it is
worth to implement or not such solution.  My idea is to see how the
packages cluster based on the synopsis+description information, then
ideally based on this, we should be able to define package similarity
and "synonyms".

Well, if you are student and you are looking for a cool project about
Machine Learning and Data Science, ping me. :-)

1: <https://en.wikipedia.org/wiki/Autoencoder>
2: <https://en.wikipedia.org/wiki/Word2vec>


Cheers,
simon

Re: Search improvements (Was: Opposition to new single-letter package name "t")

[Tobias Geerinckx-Rice]

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

Taylan,

Taylan Kammer 写道：
> This discussion made me realize that "guix search" might benefit 
> from
> the following improvement though:  I think the relevance score 
> for a
> search result should be increased significantly if the searched 
> word is
> a standalone (not substring) part of a package's name when the 
> name is
> split into dash-separated words.

Thanks for remembering ‘guix search’!  It didn't occur to me at 
all.

For most upstreams whether or not dashes were in vogue[0] when 
they named their project is literally arbitrary.  We'd penalise 
many other packages like texlive-todonotes, open{ssh,vpn,*}, 
ktexteditor, r-performanceanalytics, qutebrowser, ...  It's not a 
net win.

If I might pet my own peeve, I think clever heuristics appear 
necessary in part because %package-metrics grossly overscores 
package names.  Rank them *below* synopsis & description--which 
will contain the name anyway--with a metric of 1, maybe 2.  Enough 
to keep the relevant stuff above the irrelevant stuff (python- > 
ruby-, etc.) without distorting things as they do now.

Kind regards,

T G-R

[0]: Not a joke.

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

Re: Search improvements (Was: Opposition to new single-letter package name "t")

[zimoun]

Hi Tobias,

On Tue, 9 Mar 2021 at 18:14, Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> For most upstreams whether or not dashes were in vogue[0] when
> they named their project is literally arbitrary.  We'd penalise
> many other packages like texlive-todonotes, open{ssh,vpn,*},
> ktexteditor, r-performanceanalytics, qutebrowser, ...  It's not a
> net win.

I am not sure to understand what you mean here.

> If I might pet my own peeve, I think clever heuristics appear
> necessary in part because %package-metrics grossly overscores
> package names.  Rank them *below* synopsis & description--which
> will contain the name anyway--with a metric of 1, maybe 2.  Enough
> to keep the relevant stuff above the irrelevant stuff (python- >
> ruby-, etc.) without distorting things as they do now.

I really did math, i.e., write the scoring function, something like
(to simplify)

  score(package, query) = sum_{term in query} (wS cS + wD cD + w)

where wS, wD, wN are the weights for synopsis, description, name and
cS, cD, cN are the number of occurrences.  Then for example computed
Jacobian and so on in order to see the relation between the weights w*
and the number of occurrence c*.  Or I gave a look at the condition to
have:

  score(package_1, query) = score(package_2, query)

and basically, using the linear relevance as it is currently, the
weight (%package-metrics) are not so bad; you cannot find a really
better heuristic.  Another conclusion is: it really depends on the
number of terms the query has.  Basically, if you type one term, you
know what you are looking for and it is the package name but your are
not sure.  For more terms, currently the result strongly depends on
the quality of the synopsis and description.  For instance, try:

  guix search gnu compiler

and compare the description of all the packages with a relevance
higher than 4 (gcc-toolchain).  Well, with a linear and local scoring
function as it is currently, you cannot improve much, IMHO.  By local,
I mean only considering the words of one package independently of the
words of other packages.  That's why TF-IDF [1].  For a concrete
example, see <https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00252.html>.
  Once you have a TF-IDF, the natural scoring is BM25 [2].  Well, it
is included in Xapian and there is a patch by Arun using Xapian as a
backend for "guix search", see
<http://issues.guix.gnu.org/issue/39258#14>.  It is missing a good
evaluation, i.e., queries examples.  I have asked such examples (what
query an user type and what they are expecting) here
<https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00190.html>
but no one replied and since I am enough comfortable with searching
with Guix and other bugs are more annoying for my workflow, I moved to
other stuff.

For another discussion on the topic, see
<https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00222.html>.


Since 2020, I have read pieces of "word embdeding" (part of vogue[0]
graph neural nets), and I think it would a great project: first some
vogue[0] stats to evaluate how the packages cluster together, i.e., is
emacs-foo closer to emacs-bar or python-foo?  and second depending on
the results, implement such embdeding to improve "guix search".  The
first means use Julia (or package PyTorch for Guix ;-)) and the second
means implement targeting Guile (it could awesome to have an
equivalent to Zygote [3,4] for Guile).

0: Not a joke. :-)
1: <https://en.wikipedia.org/wiki/Tf%E2%80%93idf>
2: <https://en.wikipedia.org/wiki/Okapi_BM25>
3: <https://github.com/FluxML/Zygote.jl>
4: <https://arxiv.org/pdf/1810.07951.pdf>


Cheers,
simon