Consistent `withPackages` naming

Development
1

In haskell we have ghcWithPackages, in python we have python.withPackages in R we have rWrapper.override { packages = [...];}. Why are these different? Can we pick a consistent naming scheme?

I’m happy to implement it, but I don’t know if the community has preferences for one format or if there’s some reason they’re different.

6 Likes
2

I recently implemented kodi.withPackages and have started work on implementing retroarch.withPackages… so that is my vote :+1:

1 Like
3

My understanding is that, the reason similar things are named differently is because they were implemented by different people, and there was no attempt to try to be consistent with naming.

Nixpkgs often ends up being divided into “kingdoms”, where different groups of people are in charge of different parts, and they often don’t contribute to other parts. For instance, as far as I know, none of the Python maintainers frequently contribute to the Haskell infrastructure, and none of the Haskell maintainers frequently contribute to the Python infrastructure.

Personally, I think it would be great to have consistent naming, but I imagine you’d get some push-back from people that value backwards compatibility more than consistent naming.

I’m happy to implement it

In my opinion, implementing it would be the easy part, but the following things would take much more time:

  • arguing that this change should actually happen
  • documenting it (including all the “official” or “semi-official” out-of-tree documentation)
  • making sure the community uses the new names going forward

If I were to go about trying to tackle this, my first step would be trying to get an informal buy-in from the maintainers of all the different parts of Nixpkgs that will need to change. After people are on-board, open up an RFC detailing exactly what needs to happen. As long as the maintainers are on-board, I imagine the RFC would mostly(?) be a formality, but it would probably be convenient to have something to point to if there is any push-back when actually trying to update things.

8 Likes
4

ghc.withPackages already exists, only thing that’s lacking currently is that haskell.compiler.ghc*.withPackages is missing, but the same can be achieved via haskell.packages.ghc*.ghc.withPackages.

2 Likes