Nixpkgs: Prefix haskell package name with "haskell-"

[matthewbauer]

Issue description

This is related to Repology. Basically all of the haskell packages use the name attribute for just their name. It would be nice to prefix it with something like "haskell-" to make it obvious that this is the "haskell" version of the package and not something else with the same name.

See: https://repology.org/metapackage/a50/related

/cc @peti

[FRidh]

This should also be part of a discussion on standardization among the sub package sets.

[peti]

We used to have haskell- prefixes but dropped them a long time ago because they serve no purpose inside of Nixpkgs.

[ryantm]

Having something in the name would be nice when looking at store paths.

[matthewbauer]

It’s interesting how many different ways package managers name them. Here are all packages for the containers module:

https://repology.org/metapackage/haskell:containers/versions

• Ports uses hs-
• Lots of Linux users use ghc- including guix
• Others use Haskell-

It doesn’t rreally matter which one we use just that there’s a way to differentiate between haskell and nonhaskell packages.

[FRidh]

In case of Python we have a prefix that describes what interpreter it is for, both implementation and language version.

[dezgeg]

Shouldn't we be telling Repology attr paths, not names in derivations? Then we'd tell them haskellPackages.foo with no effort.

[ryantm]

@dezgeg The attrpaths feel like some internal nixpkgs detail to me.

[ryantm]

On the other hand, we are saying we want people to use nix-env -A all the time, so maybe not.

[ryantm]

This file in the Repology source is good inspiration for how other package repositories handle this this kind of problem:

https://github.com/repology/repology-rules/blob/cf597026b26d56411db1245c9728226f09feb56c/500.wildcard.yaml#L52

Repology disambiguates sub package sets by using a name: prefix, like haskell:a50.

If we added a rule like this, it would handle this for us on Repology:

- { setname: "haskell:$0", noflag: not_haskell, name-pat:"(.*)", wwwpart: hackage.haskell.org, family: [nix-unstable, nix-stable] }

I'll work on getting that rule in, but it seems like it would be worth changing the name of the package for more general usage.

[ryantm]

Oh, sorry, that doesn't work because not all haskellPackages packages have a Hackage homepage. It looks like I can fix the rPackages though because they are all prefixed by r-.

[ryantm]

Here is the fix for the rPackages https://github.com/repology/repology-rules/pull/30

[peti]

That doesn't work because not all haskellPackages packages have a Hackage homepage.

It would be fine to change our package set so that Hackage package refer meta.homepage to Hackage rather than the URL given in the Cabal file. Those URLs are oftentimes flat out wrong. The Hackage URL, however, is definitely correct and it's also not going to disappear over time, so arguable it's more valuable for our users.

Generally speaking, I think this problem should be solved in the code that generates the package list, i.e. there should be some general-purpose mechanism that maps from a nested attribute path into a prefixed package name so that haskellPackages.foo can come out as haskell-${haskellPackages.foo.name}. The same mechanism can be useful for other cases, like Emacs packages, gnome packages, and whatnot.

[globin]

@AMDmi3 has already said he's ok with our current format: https://github.com/repology/repology/issues/560

[peti]

@globin, do I understand that repology ticket correctly when I interpret it as saying that they will extend their harvester so that it no longer classifies our R and Haskell packages as "meta packages"?

[AMDmi3]

I wanted to do this, but I hoped that it would only be a temporary fix. If nix haskell packages are prefixed, it won't be needed.

[ryantm]

@AMDmi3 I have a solution: we can update the nix.py parser to look for keys starting with haskellPackages and immediately prefix "haskell:" to the package name. I'm working on this currently

[matthewbauer]

I guess this is fine to look at other things in repology. But shouldn’t haskell packages be prefixed regardless of how repology works? That’s at least consistent with how most other language packages work. In addition they’ll be grouped together in the package search & avoid potential name collisions with non-Haskell packages.

[oxij]

I guess this is fine to look at other things in repology. But shouldn’t haskell packages be prefixed regardless of how repology works?

I completely agree. After 4a8797d8276aa1bd9c09d1f591eef1bd04adf2ec was commited, nix's "to be built" list became really confusing, so I reverted that commit. I'm really surprised nobody voiced the intention to do the same before now.

In case anyone cares I vote for ghc-${version}- prefix. You'd be surprised how helpful that is. Like you'd immediately notice that older ghcs are build just for a single jailbreak-cabal binary.

[ryantm]

Another issue to consider is that some Haskell packages are already prefixed with haskell-. For example, https://hackage.haskell.org/package/haskell-abci . It seems nice that Repology uses : for separating the package namespaces because a : is less likely to appear in the name of a package.

[peti]

@oxij, can you please share more detail about which particular jailbreak binary is build with an older version of ghc? I looked around the source code in master and I can find any such case.

[peti]

Ah, nevermind. I found haskell.packages.ghc822.jailbreak-cabal. That override is necessary, unfortunately, because of issues with Cabal 1.22.x. I'll try whether I can find a less expensive solution.

[ryantm]

@globin Can we reopen this because it does not seem like there is consensus on prefixing?

[ryantm]

I fixed the prefixing issue relating to Repology by using the first part of the attrpath (if the attrpath has a . in it) as a package "category", and making a rule that prefixes haskell: to the name of any nix package with the category haskellPackages. For example, https://repology.org/metapackage/haskell:mtl/versions .

I think this issue should remain open because we haven't finished resolving the other potential issues regarding prefixing or not.

[AMDmi3]

Just my 2 cents, if nix community decides to prefix haskell packages (I fully support this idea), please notify me beforehand so I could add corresponding rule and avoid package names bouncing back and forth in repology, polluting feeds.

[ryantm]

@matthewbauer Why did you close this?

[matthewbauer]

I've change my mine on this one. IMO the rule should be-

1. If your package set uses recurseIntoAttrs, then you MUST prefix each package name with the language.
2. If your package set does not use recurseIntoAttrs, you can choose to prefix or not.

Haskell doesn't use recurseIntoAttrs so this seems fine.