I like the intention, but don't like the _. Just a $0.02.

What do you propose? I went with an underscore because there are already two packages doing this in nixpkgs.

Please also add renamed packages to pkgs/top-level/aliases.nix

I wonder what's the precedent, in major packaging systems. Have you looked?

Nitpick: you forgot 2048-in-terminal.

I wonder what's the precedent, in major packaging systems. Have you looked?

Not yet, I will research a bit.

Nitpick: you forgot 2048-in-terminal.

Ah, right. I forgot to link it: 2048-in-terminal is addressed in #33846

Other package managers do not avoid names starting with digits:

• http://gpo.zugaina.org/net-nds/389-ds-base
• https://aur.archlinux.org/packages/389-ds-base/

It seems that this issue is better addressed in Nix rather than in Nixpkgs: [ 2bwm ] should not be parsed as [ 2 bwm ].

Hmm, changing nix for this is an interesting option. Still, my eye might tend to parse "389-ds" as subtraction...

The eye will adjust. Nix supports - in attribute names, and I don't think that a-4-b (an ID) should be parsed differently from 4-a-b (currently a subtraction of a-b from 4).

It would be quite an incompatible change. When I remember how the "x:x" change goes...

I have checked that modifying the lexer to support IDs starting with an integer (and prioritizing INTs to IDs to disambiguate) does not affect parsing of any .nix file in Nixpkgs master. I am going to make a PR with this change (after adding tests). WRT this PR, I'd prefer that names in all-packages.nix continue to begin with digits; underscored aliases may be added to aliases.nix.

In 0b16704#r14008920 @edolstra said:

Please don't start package names with a digit. It confuses nix-env and requires quoting of attributes.

But e.g. nix-env -iA 2048-in-terminal works, and the proposed change will obsolete quoting. (nix-env -i 2048-in-terminal works too.)

@orivej I didn't consider changing Nix syntax. I'm not sure about it though.

(however this gets resolved, please include 2048-in-terminal here as well, since it should be handled the same as others in this PR. Thanks!)