input-output-hk/stack2nix

Custom setups don't work

Opened this issue · 5 comments

lally commented

Custom setups in the .cabal file don't quite work right. As an example, projects using proto-lens won't find proto-lens-protoc, complain about it, and fail.

So perhaps a way to run then correctly, it at least documentation on how's to duplicate their functionality, would be quite useful.

@lally Sometimes the generated packages won't have overrides set correctly. I'm not exactly sure why this is but I think it is a cabal2nix vs. hackage2nix thing.

For instance, if you use cabal2nix to generate a derivation for proto-lens-protoc, it will look like this:

$ cabal2nix cabal://proto-lens-protoc
{ mkDerivation, base, bytestring, containers, filepath
, haskell-src-exts, lens-family, pretty, proto-lens, protobuf
, stdenv, text
}:
mkDerivation {
  pname = "proto-lens-protoc";
  version = "0.5.0.0";
  sha256 = "161dcee2aed780f62c01522c86afce61721cf89c0143f157efefb1bd1fa1d164";
  isLibrary = true;
  isExecutable = true;
  libraryHaskellDepends = [
    base containers filepath haskell-src-exts lens-family pretty
    proto-lens text
  ];
  libraryToolDepends = [ protobuf ];
  executableHaskellDepends = [
    base bytestring containers lens-family proto-lens text
  ];
  homepage = "https://github.com/google/proto-lens#readme";
  description = "Protocol buffer compiler for the proto-lens library";
  license = stdenv.lib.licenses.bsd3;
}

However, if you look at pkgs/development/haskell-modules/hackage-packages.nix in nixpkgs, the proto-lens-protoc definition looks like the following:

  "proto-lens-protoc" = callPackage
    ({ mkDerivation, base, bytestring, containers, filepath
     , haskell-src-exts, lens-family, pretty, proto-lens, protobuf, text
     }:
     mkDerivation {
       pname = "proto-lens-protoc";
       version = "0.5.0.0";
       sha256 = "0r6il4gvvcggxxbz2hq1kkw1qwk1rspqcb2j04ngd06pmvicw78n";
       isLibrary = true;
       isExecutable = true;
       libraryHaskellDepends = [
         base containers filepath haskell-src-exts lens-family pretty
         proto-lens text
       ];
       libraryToolDepends = [ protobuf ];
       executableHaskellDepends = [
         base bytestring containers lens-family proto-lens text
       ];
       description = "Protocol buffer compiler for the proto-lens library";
       license = stdenv.lib.licenses.bsd3;
     }) {inherit (pkgs) protobuf;};

You can see that the protobuf argument is being set to the top-level protobuf derivation (in the final inherit line). This is needed because there is both a top-level protobuf derivation, as well as a Haskell package called protobuf. Without this, the Haskell callPackage gets confused about what protobuf should be used.

I think stack2nix directly uses cabal2nix, so you'll have to do these types of overrides yourself.

lally commented

@cdepillabout First, thanks for answering.

If I understand you correctly, the pkgs/development/haskell-modules/hackage-packages.nix definition of "proto-lens-protoc" will bind to the top-level (non-haskell) protobuf derivation instead of haskell-packages.protobuf derivation.

Ok, I can understand that. But it only brings up two more questions:

  1. Which one of the two versions does the "proto-lens-protoc" = (((hackage.proto-lens-protoc)."0.5.0.0").revisions).default; in my generated pkgs.nix refer to?
  2. Is that where I'd try to re-bind its argument to the global protobuf derivation?

Thanks,

  • Lally

@lally

Which one of the two versions does the "proto-lens-protoc" = (((hackage.proto-lens-protoc)."0.5.0.0").revisions).default; in my generated pkgs.nix refer to?

I believe you are using haskell.nix with nix-tools stack-to-nix utility. Not stack2nix from this repository.

lally commented

🤦‍♂️ they're different? Is this the one I should be using instead?

@lally this (stack2nix) is the old one @domenkozar initially wrote. It reuses the existing haskell infrastructure in nixpkgs. haskell.nix \w nix-tools is the new infrastructure we wrote primarily to address short comings in performance, granularity and cross compilation capabilities of the haskell infrastructure in nixpkgs. At IOHK we almost exclusively use haskell.nix these days, except for legacy code.