-
-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to deal with packages who's name is not a valid Nix identifier? #164
Comments
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 😒 |
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. |
@edolstra any objection to |
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 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". |
Any updates or any workarounds for this issue? I need to compile a package that depends on |
@edolstra wrote:
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. |
Some considerations:
|
@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 As for workarounds, I'd probably pick either adding an underscore ( |
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):
I didn't realise these were ‘variables’.
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
If someone (not me; maybe @aminb) prepared a PR for |
Can somebody remind me why we use the
convention at all as opposed to
? I understand that the latter would address most of these problems ( |
The latter approach is unidiomatic in Nixpkgs and virtually no expression in Nixpkgs does that. It's good practice to accept precisely those dependencies that you use and nothing else. Expressions are easier to read that way and they are also easier to modify without accidentally adding new dependencies that weren't there before. |
See for example: This email is Eelco coming up with the current style. Basically he likes the formal parameters. IIRC there was also some microbenchmark that showed that style was slightly faster since the C++ code did the lookup in pkgs once instead of for each attribute, but that might have changed. |
To me, this to make overriding easy. You can override just one or two inputs instead of the entire set. |
Still an issue 7 years later... |
Indeed, it is hard (to impossible) to fix if we still want to leverage splicing to facilitate correct cross compilation as it works today. Are you running into it for anything specific? |
assert package; what one can do is modify generated nix file to rename it to something like assert_pkg and ensure it's available in package set under that name there are presumably multiple ways cabal2nix can work around this but seems in name of perfection, nothing is done instead |
@sternenseemann Can you explain what that means? Why can’t we just define an injective mapping from hackage names to non-keyword nix names and apply that consistently everywhere when generating the nix expressions? |
I want to repeat my question: Where are you running into this, specifically? I'm a bit surprised by your frustration, since my impression is that it hasn't been implemented so far because the amount of pain it causes is minimal, i.e. the list of packages that have to be removed is quite short: Lines 81 to 85 in 26939db
Picking up this issue again is possible of course if it's worth it.
I think so, this occurred to me as well after thinking about it for a bit. My response was in particular about the alternative approaches presented in this issue (taking everything from the package set) where splicing would be broken: I believe we could, following general nixpkgs policy, use such an escaping logic: escapeAttrName :: String -> String
escapeAttrName a = if isValidIdentifier a then a else '_':a
unEscapeAttrName :: String -> String
unEscapeAttrName ('_':x) = x
unEscapeAttrName x = x The fact that cabal package names can never contain underscores does come in handy here. |
Honestly, I think we should do this. This is not just a question of weird corner cases, but of correctness. Especially, this could go wrong again at any time when anyone uploads anything funky to hackage so it will at least prevent breakage at an inconvenient time. |
@sternenseemann Oh, I wasn't clear. We have our own package that directly depends on Deleting stuff that depends on |
Hi, Is there a workaround?
nix files is generated with
|
As a workaround, just replace |
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 because4Blocks
is not a valid identifier. In other words, packages that depend on4Blocks
and friends cannot be built.The text was updated successfully, but these errors were encountered: