Document that `cabal.project` is used only for `packages`

[peterbecich]

I appreciate haskell-flake's support for cabal.project. I think it might be ignoring source-repository-package: https://cabal.readthedocs.io/en/stable/cabal-project.html#specifying-packages-from-remote-version-control-locations

haskell-multi-nix with example: https://github.com/peterbecich/haskell-multi-nix/tree/source-repository-package-example

https://github.com/peterbecich/haskell-multi-nix/blob/source-repository-package-example/cabal.project

This should attempt to pull haskell/text bogus commit 123 cabal.project

packages:
    ./foo
    ./bar

source-repository-package
  type: git
  location: https://github.com/haskell/text.git
  tag: 123
  -- tag: 73620de89d43ee50de2d15b7bc0843bf6d6e9b9a

cabal build all fails as it should. However, nix build succeeds; I think it is getting text from NixPkgs as usual.

Cabal pulls the real commit 73620de correctly. nix build doesn't indicate if it is pulling this commit or not.

---

I know the text dependency could be specified in flake.nix: https://community.flake.parts/haskell-flake/dependency/#path

Thank you

[shivaraj-bh]

haskell-flake only parses packages from cabal.project, nothing else.

[srid]

Yea, this is not supported, but we should document it clearly. You want to specify those source dependencies as flake inputs instead: https://community.flake.parts/haskell-flake/dependency#path

[peterbecich]

Thanks, https://community.flake.parts/haskell-flake/dependency#path works great.

In some cases, if the source-repository-package is kept in cabal.project, it appears to cause an error in haskell-flake. Example: https://github.com/peterbecich/halogen-chess/tree/source-repository-example Here is the error:

$ nix build 
error: builder for '/nix/store/5f7by9iws9vrakc33sgar5iczyqqv8hx-source-halogen-chess-sdist.tar.gz.drv' failed with exit code 1;
       last 8 log lines:
       > unpacking source archive /nix/store/7p1dwmwzp50sxxp4jivnkl22qvpvqffy-source-halogen-chess
       > source root is source-halogen-chess
       > Config file path source is default config file.
       > Config file not found: /build/source-halogen-chess/.config/cabal/config
       > Writing default configuration to
       > /build/source-halogen-chess/.config/cabal/config
       > Error: cabal: The program 'git' is required but it could not be found.
       >
       For full logs, run 'nix-store -l /nix/store/5f7by9iws9vrakc33sgar5iczyqqv8hx-source-halogen-chess-sdist.tar.gz.drv'.
error: 1 dependencies of derivation '/nix/store/31ywv0x3cwdwlcx3l5rxmmmswsr2w6km-halogen-chess-0.1.0.0.drv' failed to build

That contradicts the example I started this issue with, where haskell-flake ignores source-repository-package: https://github.com/peterbecich/haskell-multi-nix/blob/source-repository-package-example/cabal.project I'm not sure why in the first project source-repository-package is ignored, and in the second project it results in this Git error. Both projects updated to latest haskell-flake; both use flake-root.

In the example project with build error, removing source-repository-package will make nix build succeed. I want to keep source-repository-package so the project is buildable by either plain Cabal, or Nix with haskell-flake.

Can haskell-flake's cabal.project parser be modified to always ignore the source-repository-package?

[srid]

haskell-flake itself ignores everything but packages -- so it does ignore source-repository-package. Maybe cabal (as invoked from Nix) is the only one that is forcefully using it?

In your first project, your only local package lives at project root, hence /cabal.project gets included in sdist of your only package. You can have haskell-flake ignore cabal.project entirely by manually specifying the path:

haskellProjects.default = {
  packages.halogen-chess.source = builtins.path { path = ./.; filter = path: _: baseNameOf path != "cabal.project";;
}

(Perhaps we should have a packages.*.filter option to specify these patterns directly?)

[peterbecich]

You're correct, thanks! Moving halogen-chess.cabal into a subdirectory fixes it: https://github.com/peterbecich/halogen-chess/tree/fix-cabal-project-in-nix/haskell by keeping cabal.project out of the sdist.

I can't get the second solution working; these cause infinite recursion. I can probably fix this with https://community.flake.parts/haskell-flake/package-set ; will report back.

packages = {
  halogen-chess.source = builtins.path {
    path = ./.;
    # filter = path: _: baseNameOf path != "cabal.project";
  };
};

packages = {
  halogen-chess.source = builtins.path {
    path = ./.;
    filter = path: _: baseNameOf path != "cabal.project";
  };
};

packages = {
  halogen-chess.source = ./.;
};

[peterbecich]

I'm going to try to reproduce this with the fundamental make-package-set functions https://github.com/NixOS/nixpkgs/blob/e35d582350f5b92c769161532a663fb7fcce74f7/pkgs/development/haskell-modules/make-package-set.nix#L552-L597 , and then find or file an issue in nixpkgs

---

Cabal has an --offline flag. Maybe I need to check if make-package-set is using it, and if it would help.

              cabalFlags.offline = true;
              extraConfigureFlags.offline = true;
              extraBuildFlags.offline = true;

still results in

> Error: cabal: The program 'git' is required but it could not be found.

https://github.com/peterbecich/halogen-chess/blob/f52f62b882d7311792212a58447d54171912111b/flake.nix#L169-L171

---

The --offline flag does not disable source-repository-package in Cabal; I have filed an issue: https://github.com/haskell/cabal/issues/9641 Maybe the test above will succeed if this is fixed.

[srid]

It needs to be self instead of ./.; but builtins.filter still doesn't work due to the way local packages are detected. This requires some debugging (and I have other things of priority to take care), so in the meanwhile perhaps you want to move cabal.project out of the way somehow? Eg. git mv cabal.project cabal.project.template (and ask users to move it back when using non-nix setup).

But yea, leveraging the --offline flag, while having it work correctly, would be one proper fix here. Another solution is to implement the filter option I mentioned above. This seems like a trivial solution that's not hacky.

[peterbecich]

Thanks for your time, @srid