`hoogle generate --local` ignores `haddock-html` field

[LightAndLight]

Tested at commit e11273e.

When I try to generate a Hoogle database on NixOS (in a Nix shell that provides GHC, Cabal, and Hoogle), I get the following error:

$ hoogle generate --local --database db.hoo
Starting generate
Reading ghc-pkg... 0.03s

Packages missing documentation: array base binary bytestring Cabal Cabal-syntax containers deepseq directory exceptions filepath ghc ghc-bignum ghc-boot ghc-boot-th ghc-compact ghc-experimental ghc-heap ghc-internal ghc-platform ghc-prim ghc-toolchain ghci haskeline hpc integer-gmp mtl os-string parsec pretty process rts semaphore-compat stm system-cxx-std-lib template-haskell terminfo text time transformers unix xhtml
No packages were found, aborting (use no arguments to index all of Stackage)

I found that the readGhcPkg function made too many assumptions about the location of package documentation.

I have a fix here, but I think the code could be improved.

[Bodigrim]

I agree that feeding ghc-pkg into readCabal is a big hack, but what was exactly the issue on NixOS that readCabal didn't cope?

[LightAndLight]

It looks like my diagnosis was incorrect.

readCabal unconditionally returns a Package with packageDocs = Nothing (so g <$> packageDocs p in readGhcPkg is dead code). Therefore the source Conduit in Action.Generate:readHaskellGhcpkg iterates over a list of packages that have packageDocs = Nothing, so the whenJust fires for no packages.

This suggests that hoogle generate --local is broken everywhere.

The unconditional packageDocs = Nothing seems suspicious, so I looked at the Git blames. It looks like the haddock-html field got lost in this commit when removing a custom parser in favour of GenericPackageDescription. Unfortunately I don't see where to find the haddock-html in a GenericPackageDescription or the PackageDescription contained within. Maybe instead it can use an InstalledPackageInfo (via parseInstalledPackageInfo)?

[Bodigrim]

This suggests that hoogle generate --local is broken everywhere.

I think you are right. That's unfortunate.

What I've been trying to say is that readCabal is simply wrong here: the output of ghc-pkg is not a valid Cabal file, even if roughly resembles one.

Maybe instead it can use an InstalledPackageInfo (via parseInstalledPackageInfo)?

Hmm, I never used this one, but it looks about right. Would you like to give it a spin?

[LightAndLight]

Would you like to give it a spin?

Sure thing.

The ghc-pkg docs say that InstalledPackageInfo defines the format of ghc-pkg outputs, so I'm optimistic.