`cabal build` doesn't find public sub package within development shell but builds fine with nix build.

[MangoIV]

When trying to cabal build a package that contains a public sublibrary, cabal fails to find this library within a shell provided by haskell.nix.

Somehow everything builds just fine with nix build.

Reproducer fails with:

Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: blup-0.1.0.0 (user goal)
[__1] next goal: bla (dependency of blup)
[__1] rejecting: bla-0.1.0.0/installed-Hsuvz2e1aJzCilZPkGBZy8 (does not
contain library 'blabla', which is required by blup)
[__1] fail (backjumping, conflict set: bla, blup)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: blup, bla

[L-as]

Does this happen with source-repository-package?

[MangoIV]

like, when I declare the dependency in a cabal.project file?

[L-as]

yeah

[L-as]

but if you do it through cabalProjectLocal when calling cabalProject'.

[MangoIV]

Can anyone point me at where this

bla-0.1.0.0/installed-Hsuvz2e1aJzCilZPkGBZy8

comes form? Maybe I can fix it if I know.

[MangoIV]

If I put a sourc-repository-package into the cabalProjectLocal, it doesn't get picked up by the shell either. (This time, the entire package is missing)

I still works for the nix build.

[MangoIV]

I'm thinking that something's wrong with shell. (or the way I used it.)

[MangoIV]

I think I found the issue:

 131   │   # Collect all (transitive) Haskell library dependencies of a
 132   │   # component.
 133   │   ## flatLibDepends :: Component -> [Package]
 134   │   flatLibDepends = component:
 135   │     let
 136   │       makePairs = map (p: rec { key=val.name; val=(p.components.library or p); });
 137   │       closure = builtins.genericClosure {
 138   │         startSet = makePairs component.depends;
 139   │         operator = {val,...}: makePairs val.config.depends;
 140   │       };
 141   │     in map ({val,...}: val) closure;

this doesn't include components.sublibs

[hamishmack]

Unfortunately I don't think that is it. The reason it does not have components.sublibs is that the nix-tools output for dependencies is explicit for sublibs (so project.plan-nix should have something like depends = [ bla.components.sublibs.bla ] in it). We were thinking about making it explicit for dependencies on the default library was well (#1679), but I am not sure it is worth increasing the size of the nix output.

I think the problem is more likely that the way we are making package DB entries for sublibs is not what cabal expects. So it works with builders/component-builder.nix, but not with cabal build.

I think we should try to compare the the package DB entries that cabal build creates when not in a haskell.nix shell (I guess they will be in dist-newstyle somewhere), with those provided in the haskell.nix nix-shell (as in the ones in the ghc-pkg list output in the shell).

[MangoIV]

if I add the sublibs in the flatLibDepends function, the derivation gets added to buildInputs which before isn't the case ghc-pkg list includes the sublib dependency but marks it as blue. cabal also doesn't recognise the sublib.

[MangoIV]

It also seems like its given a weird name, in case of my reproducer:

/nix/store/5kyyvr8cd18a9bhfklrqk7hwprjwadaj-ghc-shell-for-blup-ghc-8.10.7-env/lib/ghc-8.10.7/package.conf.d
    array-0.5.4.0
    base-4.14.3.0
    bla-0.1.0.0
    z-bla-z-blabla-0.1.0.0 -- this is blue
    deepseq-1.4.4.0
    ghc-boot-th-8.10.7
    ghc-prim-0.6.1
    integer-gmp-1.0.3.0
    pretty-1.1.3.6
    rts-1.0.1
    template-haskell-2.16.0.0
/home/mangoiv/.ghc/x86_64-linux-8.10.7/package.conf.d
    (no packages)

[MangoIV]

so the reason it does not look up the components.sublib is that when you're trying to add the library you need to be explicit about it and if not, it just assumes that it's a sublib?
Can this not be documented in all modules this knowledge is needed?

[MangoIV]

It seems the normal nixpkgs haskell infrastructure also can't handle sublibs.

[MangoIV]

NixOS/nixpkgs#191481

[MangoIV]

@hamishmack as you suggested I investigated the package-db that's generated by haskell.nix a bit more and it seems to be exactly the same if I compare it to the one generated when trying to build via cabal.project.
I have some suspicions atm:

• the abi hash being not what ghc expects
• the resolver running although it doesn't have to (can I make cabal skip the resolving step?)
• something that gets put into the ~/.cabal folder that's being skipped when building. (I have not investigated that yet)