How to deal with packages who's name is not a valid Nix identifier?

[peti]

• The Haskell package assert conflicts with the reserved keyword in Nix.

• The Haskell package type conflicts with the internal attribute of the same name used in Nix derivations.

• Packages like 4Blocks cannot be passed as arguments to other builds because 4Blocks is not a valid identifier. In other words, packages that depend on 4Blocks and friends cannot be built.

[shlevy]

I'd like to be able to have quoted attribute names in function bindings. But without that, probably the only way to do this is to do args@{ ... } and explicitly pass in 4Blocks to everything that references it 😒

[Mathnerd314]

What about munging the package names? Say 4Blocks becomes x-4Blocks (and x- becomes x2-, x3- x4-, and so on, although hopefully hackage will never have any packages starting with x-). Then add an extra pass at the end to assign the proper attributes their proper values.

[shlevy]

@edolstra any objection to { "4Blocks" }@args: args."4Blocks" being valid nix?

[edolstra]

I'm not really opposed to it being valid, but I don't think it's a good idea to use it in Nixpkgs because it's pretty ugly. Munging the package name (like _915resolution) is also ugly, but doesn't require special syntax.

Another reason not to do this: the first name component that starts with a digit signifies the start of the version. So "4blocks" might be interpreted as a package with an empty name and a version of "4blocks".

[bandali]

Any updates or any workarounds for this issue? I need to compile a package that depends on assert, and I'm not sure how to proceed.

[liyang]

@edolstra wrote:

[…] I don't think it's a good idea to use it in Nixpkgs because it's pretty ugly.

I don't understand this objection to optional double-quoting of troublesome names, on the basis of aesthetics. The alternative is that you have a package manager that's not fit-for-purpose.

[edolstra]

Some considerations:

• It's not just aesthetics, it's also confusing. The "4Blocks" in { "4Blocks" } looks like a string, not a variable name.

• You can't refer to such variables directly, so you need tricks like { ... }@self: ... self."4Blocks".

• Even if we added support for this now, you wouldn't be able to use it for a while in Nixpkgs for compatibility reasons.

• Most package managers have naming rules, so to say that having a few rejected packages names makes Nix unfit-for-purpose seems hyperbolic.

[bandali]

@liyang and @edolstra thanks for chiming in!

While I do agree that the situation is unfortunate, I think having some workaround is better than none. And better late than never, I guess :) For the short term I can copy the stuff I need from assert into our codebase (giving proper credit to @liyang of course) but I don't like to literally duplicate code like that.

As for workarounds, I'd probably pick either adding an underscore (_) to the beginning of package names that are invalid identifiers (e.g. assert becomes _assert, or type becomes _type); or the quoting approach with @. I'm leaning towards the first one, but I'm not a seasoned nix user and I'm just putting the thought out there.

[liyang]

Hello @edolstra!

Firstly I must admit that I don't know Nix (the language), nor do I use Nix (the distro), so I have a few questions (and apologies if they're basic/obvious):

The "4Blocks" in { "4Blocks" } looks like a string, not a variable name.

I didn't realise these were ‘variables’.
Why must this variable name coincide with the upstream name though, with no room for exceptions?

Most package managers have naming rules, so to say that having a few rejected packages names makes Nix unfit-for-purpose seems hyperbolic.

Sorry, that was purely to get your attention. :)

That said having Hackage packages that are unpackageable under Nix does seem very wrong to me. Is it just a lack of contributor effort to cabal2nix that's preventing us from having a simple consistent workaround for troublesome package names? Earlier you wrote:

Munging the package name (like _915resolution) is also ugly, but doesn't require special syntax.

If someone (not me; maybe @aminb) prepared a PR for cabal2nix to munge troublesomes names—in whatever way you find least objectionable—would you be prepared to merge it?