Nixpkgs: Naming of packages

[FRidh]

The Nixpkgs manual has a section on package naming.

At the sprint a couple of us in _the Python room_ discussed this issue regarding Python packages. Right now, the guidelines say we should follow the upstream name, but still, convert to lowercase. What are the arguments for following upstream name, and what are the arguments for adapting the name?

Some reasons for sticking with upstream naming:

• No guessing needed to get the right package on Nix
• Especially helpful with security updates
• Allows more automation of packaging. E.g., in the case of pypi2nix (@garbas).

Some reasons for changing naming, e.g. lowercasing:

• Consistent style
• The shift button lasts a bit longer

Also, how is taken care of this issue in other parts of Nixpkgs, e.g. haskell?

[domenkozar]

cc @jagajaga

[vcunat]

In TeX Live I used upstream names exactly. I was lazy to transform them during the generation process. (I used quoting instead, as some start with digits, etc.)

[peti]

Haskell packages use the upstream names without any transformation. This causes plenty of trouble, btw, because we cannot have a package called "assert" or "type". Also, package names like "3d-graphics" seem to work at first glance, but there is no way to refer to that package in a function argument list:

{ "3d" = ...; }

is fine, but

 { "3d" } : ...

is not. So far, I deal with these issues by firmly looking the other way, i.e. packages with illegal names are simply broken. I'm not sure what else to do.

[jagajaga]

@peti maybe we should create come prefix for this kind of pkg? Like nix3d or something else. Because ugly named pkg is better than non-working pkg.

[spinus]

or maybe allow nix to use that "crazy" names and keep original names for all packages?

Small comment from person who is testing nixos for 2 months as user/admin. It's a little crazy that there are 3 names for packages which gives me a lot of headaches and I waste time because of this.

For most user/admin tasks you need one name, the package name. In certain situations you need source package name which can generate few different packages (in nix it's attribute name).

1. that's crazy that in nixos source package and package names are completely different even it it's 1:1 mapping (for example vimPlugins.ipython -> vimplugin-vim-ipython-2015-06-23)
2. names of packages are very inconsistent, example:

nixos.pythonDocs.pdf_letter.python31                            python31-docs-pdf-letter-3.1.5
nixos.python34Packages.sip                                      sip-4.14.7

that's cool that python libraries are prefixed with python- and "programs" are not, but why attribute name is not following that pattern?
Also, some packages are not even following prefix pattern, for example syncthing is a program and in nixos its name is:

nixpkgs.go14Packages.syncthing                                  go1.4-syncthing-v0.11.25
nixpkgs.go14Packages.syncthing-lib                              go1.4-syncthing-v0.11.25
nixpkgs.syncthing                                               go1.4-syncthing-v0.11.25

?? It's confusing.

1. There is third name in nixos, in nixpkgs in top-packages.nix:

  googleAuthenticator = callPackage ../os-specific/linux/google-authenticator { };

For some packages the same name is used and that very nice, but what's a huge duplication, so much writing:

  dnstop = callPackage ../tools/networking/dnstop { };
  dhcp = callPackage ../tools/networking/dhcp { };
  dhcpdump = callPackage ../tools/networking/dhcpdump { };
  dhcpcd = callPackage ../tools/networking/dhcpcd { };
  di = callPackage ../tools/system/di { };
  diffoscope = callPackage ../tools/misc/diffoscope { };
  diffstat = callPackage ../tools/text/diffstat { };
  diffutils = callPackage ../tools/text/diffutils { };

What do you think guys about just keeping nix files with packages in directories and import them all during build time? This will simplify a lot from management point of view, adding packages, updating them will be much easier which can as well be on of the factors to attract users. That's what happened to Arch, it's extremely easy to build a package, write a file, put it and go!

I know that sometimes there is a need to pass environment or arguments to callPackage function, but maybe that can be done "automatically" or by some injection mechanism?

As well, the default.nix for packages is a little redundant, if I understand correctly nixos don't want to keep all versions like for example gentoo is doing, it wants to roll :-) There are of course special packages like python, gcc and few others and then you are using more nix files per package, but woulnd't be simples just instead of:

package1/default.nix
package2/default.nix
package3/1.0.nix
package3/2.0.nix

just have

package1.nix
package2.nix
package3-1.0.nix
package3-2.0.nix

?

[garbas]

Hi Tomasz,

This is a known issue. Although there are not 3 names for a package but 2.
Which is still problematic. This was mentioned in Eelco's talk[1], and package
names will go away with future releases of nix we will refer to via attr path.

[1] https://www.youtube.com/watch?v=QvH5qU1qBXY&list=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy

Quoting Tomasz Czyż (2015-11-21 23:57:50)

or maybe allow nix to use that "crazy" names and keep original names for all
packages?

Small comment from person who is testing nixos for 2 months as user/admin. It's
a little crazy that there are 3 names for packages which gives me a lot of
headaches and I waste time because of this.

For most user/admin tasks you need one name, the package name. In certain
situations you need source package name which can generate few different
packages (in nix it's attribute name).

1. that's crazy that in nixos source package and package names are completely
   different even it it's 1:1 mapping (for example vimPlugins.ipython ->
   vimplugin-vim-ipython-2015-06-23)
2. names of packages are very inconsistent, example:

nixos.pythonDocs.pdf_letter.python31 python31-docs-pdf-letter-3.1.5
nixos.python34Packages.sip sip-4.14.7

that's cool that python libraries are prefixed with python- and "programs" are
not, but why attribute name is not following that pattern?
Also, some packages are not even following prefix pattern, for example
syncthing is a program and in nixos its name is:

nixpkgs.go14Packages.syncthing go1.4-syncthing-v0.11.25
nixpkgs.go14Packages.syncthing-lib go1.4-syncthing-v0.11.25
nixpkgs.syncthing go1.4-syncthing-v0.11.25

?? It's confusing.

1. There is third name in nixos, in nixpkgs in top-packages.nix:

googleAuthenticator = callPackage ../os-specific/linux/google-authenticator { };

For some packages the same name is used and that very nice, but what's a huge
duplication, so much writing:

dnstop = callPackage ../tools/networking/dnstop { };
dhcp = callPackage ../tools/networking/dhcp { };
dhcpdump = callPackage ../tools/networking/dhcpdump { };
dhcpcd = callPackage ../tools/networking/dhcpcd { };
di = callPackage ../tools/system/di { };
diffoscope = callPackage ../tools/misc/diffoscope { };
diffstat = callPackage ../tools/text/diffstat { };
diffutils = callPackage ../tools/text/diffutils { };

What do you think guys about just keeping nix files with packages in
directories and import them all during build time? This will simplify a lot
from management point of view, adding packages, updating them will be much
easier which can as well be on of the factors to attract users. That's what
happened to Arch, it's extremely easy to build a package, write a file, put it
and go!

I know that sometimes there is a need to pass environment or arguments to
callPackage function, but maybe that can be done "automatically" or by some
injection mechanism?

As well, the default.nix for packages is a little redundant, if I understand
correctly nixos don't want to keep all versions like for example gentoo is
doing, it wants to roll :-) There are of course special packages like python,
gcc and few others and then you are using more nix files per package, but
woulnd't be simples just instead of:

package1/default.nix
package2/default.nix
package3/1.0.nix
package3/2.0.nix

just have

package1.nix
package2.nix
package3-1.0.nix
package3-2.0.nix

?

Rok Garbas - http://www.garbas.si

[spinus]

@garbas oh ok, so looks like I have to dive to it more to better understand this stuff.

Thank you for the link to the video. Cool news :-)

[Profpatsch]

(triage) Is there any action-item we can get out of this?
Maybe adapting the documentation?

[garbas]

i dont see any action-items, so i'm in favor of closing it. but i'd let @FRidh do it

[FRidh]

@peti why would you want to have { "3d" } : ... ? Do you want to generate code/functions as well? Otherwise I cannot see why you would need this.

@Profpatsch, @garbas hopefully we can find agreement in this issue on updated naming guidelines because they are needed in especially the case of generated package sets.

See also PR #17331.

[garbas]

@FRidh topic smells a bit like bikeshading. but i'll try to write some reasoning :)

i don't see any reason why we shouldn't use upstream names.

• it would be easier to use tools like vulnix to see what is being
• it does not make any difference to have it either way for tools that generate nix expressions
• (reply to @peti's consern) with pypi2nix i generated a python environment which is what you would pass into a function, eg.

{ pythonPackages }:
...
   buildInputs = [ pythonPackages."foo" ... ];
   propagatedInputs = [ pythonPackages."bar" ... ];
...

but maybe this is because in python you can only use one version of package in your python environment. i think this is the same in haskell, but i'm not an expert.

• there is also an alternative syntax you can use

{ something, ... } @ args
...
   buildInputs = [ someting args."3d-graphics" ... ];
...

this is my 2 cents, fire away :)

[spinus]

Rok, +1

2016-07-28 18:21 GMT+01:00 Rok Garbas [email protected]:

@FRidh https://github.com/FRidh topic smells a bit like bikeshading.
but i'll try to write some reasoning :)

i don't see any reason why we shouldn't use upstream names.

• it would be easier to use tools like vulnix to see what is being
• it does not make any difference to have it either way for tools that
  generate nix expressions
• (reply to @peti https://github.com/peti's consern) with pypi2nix i
  generated a python environment which is what you would pass into a
  function, eg.

{ pythonPackages }:...
buildInputs = [ pythonPackages."foo" ... ];
propagatedInputs = [ pythonPackages."bar" ... ];...

but maybe this is because in python you can only use one version of
package in your python environment. i think this is the same in haskell,
but i'm not an expert.

• there is also an alternative syntax you can use

{ something, ... } @ args... buildInputs = [ someting args."3d-graphics" ... ];...

this is my 2 cents, fire away :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/11052#issuecomment-235963652,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6CD-ky7X-rD2VWaV5kEwHTd2S2udPbks5qaOT8gaJpZM4Gi9jT
.

Tomasz Czyż

[Profpatsch]

The closer to upstream the easier is the matching. And for everything where that doesn’t work there could be meta.upstream-name.

[FRidh]

In #17331 @edolstra commented on my proposal to drop the lowercase rule

Hm, I'm not sure about dropping the lowercase rule. For predictability, it's nice to know that a package is called firefox and not Firefox (so doing nix-env -i firefox will just work).

and referred to the Fedora guidelines.

From these comments it seems there are clearly two different views on the matter:

1. stick to upstream;
2. use lowercase preferably.

[peti]

We stick to upstream names when "upstream" is another distribution, like Hackage or PyPi, because people who want to install packages called "xYz" on Hackage will typically find it easiest to install "xYz" in Nix, too, rather than "xyz". In the firefox example Eelco used, however, upstream is just a single package provider and there is no systematic naming scheme or prior expectations from our users. In that case, the simplest choice -- "firefox" rather than "Firefox" -- works best.

[peti]

Anyway, I too see no actionable items in this thread and therefore think it should be closed. It would be great if this discussion would result in concrete suggestions (a.k.a. PRs), but further discussions seems to be going nowhere.