Map `extra-libraries: FLAC` to pkgs.flac

[414owen]

I'm trying to fix the nix build of https://github.com/mrkkrp/flac, which lists

    extra-libraries:  FLAC

---

I've tried adding:

libNixName "FLAC" = return "flac"

to src/Distribution/Nixpkgs/Haskell/FromCabal/Name.hs

However this produces:

{ mkDerivation, base, ... flac, ... }:
mkDerivation {
  ...
  librarySystemDepends = [ flac ];
  ...
}

Which seems to be making the derivation recursive, as opposed to using flac from nixpkgs.

I'm not entirely sure how to deal with this apparent clash between nix and haskell package names

[sternenseemann]

Your solution is correct. Because cabal2nix can only output a bunch of names without deciding how to resolve them, it can't really deal with the problem – you need to do so manually when calling the generated expression.

let
  pkgs = import <nixpkgs> {};
in

haskellPackages.callPackage ./generated-by-cabal2nix.nix {
  inherit (pkgs) flac;
}

(When generating hackage-packages.nix in nixpkgs, hackage2nix can actually do this automatically, so your fix would benefit the package expression in nixkpgs.)

[414owen]

Interesting. A few thoughts:

1. Is there currently no way to depend on nixpkgs.x and also haskellPackages.x?
2. cabal2nix --shell also creates a recursive derivation here, even though both pkgs and haskellPackages.* are in scope. This should be fixable, right?
3. Is there a reason we can't generate something like: { mkDerivation, base, pkgs }:, where pkgs is a reference to nixpkgs proper, this would avoid confusion (not knowing which package you're looking at), and support dependencies on both versions of a package

[maralorn]

Those are good questions and you are not the first person to be annoyed by this design.

1. Not trivially. Usual workaround is to rename one dependency locally or do 3. I don‘t think cabal2nix can do any of that automatically, but I don‘t know.
2. You are right callPackage already passes in a pkgs variable, so we could do exactly that. The primary reason this is not done is overriding. If we use pkgs.flac in the derivation then you can‘t pass in another version of the flac the C library via overrides.

[sternenseemann]

You are right callPackage already passes in a pkgs variable, so we could do exactly that. The primary reason this is not done is overriding. If we use pkgs.flac in the derivation then you can‘t pass in another version of the flac the C library via overrides.

It's not just that, it is also fundamental to the design to nixpkgs that packages are passed individually via callPackage and important implementation details rely on this, e.g. cross-compilation relies on this.