Cabal/Haskell: Importing generated path module leads to large closure #164630
Description
Describe the bug
When an executable uses the "paths" module exported by a library (due to the data-dir or data-files directive in the library's cabal file), the closure of that executable is very large. It includes packages such as GHC and its documentation.
Steps To Reproduce
Steps to reproduce the behavior:
- Clone the repo https://github.com/m4dc4p/nix-cabal-data-dir-surprise
- Run
nix-store --query -R --include-outputs $(nix-build -A app). - Notice closure is small & GHC does not appear.
- Run
nix-store --query -R --include-outputs $(nix-build -A big-app). - Closure has many more entries, including GHC (/nix/store/...-ghc-8.10.7) and its documentation (
/nix/store/...-ghc-8.10.7-doc)
Expected behavior
I would not expect that using the exported "paths" module from a library would make the closure so much larger. This is pretty impactful when building docker images. In the above repo, the docker image for big-app is 425MB, while the docker image for app is only 24M:
$ ls -lah $(nix-build -A docker-big-app)
-r--r--r-- 1 justin.bailey admin 475M Dec 31 1969 /nix/store/0bvvq9sdw9bwiqbwyaidxj0wwkjmdif5-docker-image-docker-big-app.tar.gz
$ ls -lah $(nix-build -A docker-app)
-r--r--r-- 1 justin.bailey admin 26M Dec 31 1969 /nix/store/kbs7i25jnnlfcd0i9wxq68q3i829323m-docker-image-docker-app.tar.gz
Additional context
app/Main.hs conditionally imports the Paths_library module from the library package. If the module is imported and used, the closure blows up. This is due to a dependency found in the package.conf.d directory installed with library.
$ nix-store --query -R --include-outputs $(nix-build -A big-app) | grep ghc-8.10.7
/nix/store/4ycwcc6rmyx2bchr7zbigfiyklqdkfik-ghc-8.10.7-doc
/nix/store/qmcdw0bq6590082f3g6sqflqvlyvap5g-ghc-8.10.7
$ nix why-depends --precise $(nix-build -A big-app) /nix/store/4ycwcc6rmyx2bchr7zbigfiyklqdkfik-ghc-8.10.7-doc
/nix/store/j17x9cwaj4japr0mwk8nqvjgx7i6aysf-app-0.1.0.0
└───bin/app: …rld..library_datadir./nix/store/jkndj3lpq6256xyrx2miqglllpqiv4sm-library-0.1.0.0/share/x86_64-os…
→ /nix/store/jkndj3lpq6256xyrx2miqglllpqiv4sm-library-0.1.0.0
└───lib/ghc-8.10.7/package.conf.d/library-0.1.0.0-4DahppUPAwH8P1w4JjXODY.conf: …dock-interfaces:. /nix/store/qlcrbcy2la79hkz81wggdrwh720k7yhj-library-0.1.0.0-doc/share/doc/l…
→ /nix/store/qlcrbcy2la79hkz81wggdrwh720k7yhj-library-0.1.0.0-doc
└───share/doc/library-0.1.0.0/html/Library.html: …> :: <a href="file:///nix/store/4ycwcc6rmyx2bchr7zbigfiyklqdkfik-ghc-8.10.7-doc/share/doc/ghc/ht…
→ /nix/store/4ycwcc6rmyx2bchr7zbigfiyklqdkfik-ghc-8.10.7-doc
The app executable does not have any dependency on GHC:
$ nix-store --query -R --include-outputs $(nix-build -A app) | grep ghc-8.10.7
< no output >
$
Note that the app and big-app derivations compile the same source, but big-app passes a CPP flag so that the Paths_library modules gets imported and used in app\Main.hs.
This bug has come up before, though not with the data-dir aspect, as NixOS/cabal2nix#539 and #155924.
Notify maintainers
Metadata
- system: `"x86_64-darwin"`
- host os: `Darwin 21.3.0, macOS 10.16`
- multi-user?: `no`
- sandbox: `no`
- version: `nix-env (Nix) 2.6.1`
- channels(justin.bailey): `"nixpkgs, nixpkgs-21.11-darwin-21.11-darwin"`
- nixpkgs: `/Users/justin.bailey/.nix-defexpr/channels/nixpkgs`
-
(Current nixpkgs revision is 3e644bd)