find the package database the same way ghc does

[masaeedu]

Hello. Thanks for your work on this handy tool. I've often been frustrated by awk and am looking forward to replacing it in my workflow with hawk.

I'm having a bit of a hard time getting set up to use this via Nix. The tool seems to be doing some sophisticated analysis in System.Console.Hawk.PackageDbs to find out the location of an appropriate package DB. It produces the following message when its efforts fail:

Please install hawk using stack, cabal v2-run, cabal v2-install, cabal v1-sandbox, or cabal v1-install. Hawk doesn't know how to find the package database using your chosen installation method.

One solution is to now teach the tool how the Nix infrastructure deals with its package database. But if the tool just asks for the package DB using an env var or command line flag, users can be responsible for teaching it where the package database is, and the tool doesn't need to try and pattern match over the open universe of possible ways to install a Haskell executable.

Would it make any sense to look for the GHC_PACKAGE_PATH env var and just bypass all the checks in that module if it's present? AFAICT that env var should then be picked up by the ghc API lib that hint is using, so we don't need the extra -package-db arg being computed here.

An even more transparent solution would be to let the user pass through arbitrary GHC flags, including a package DB.

[gelisam]

I'm having a bit of a hard time getting set up to use this via Nix.

hawk makes heavy use of the hint library, and there is a hint issue explaining how to get hint working with nix. Does it help?

The tool seems to be doing some sophisticated analysis in System.Console.Hawk.PackageDbs to find out the location of an appropriate package DB. [...] Would it make any sense to look for the GHC_PACKAGE_PATH env var and just bypass all the checks in that module if it's present?

That's exactly what I used to do with the HASKELL_DIST_DIR and HASKELL_PACKAGE_SANDBOXES environment variables, but that broke when I added support for cabal-v2, which sometimes fills those environment variables with incorrect paths. I thus had to add the sophisticated analysis in order to first figure out which installation method is used, and then only use the environment variables which are known to contain good data with that installation method. Is GHC_PACKAGE_PATH more reliable than these other two environment variables?

One solution is to now teach the tool how the Nix infrastructure deals with its package database.

That would work too. Would you like to contribute such an entry to the list of supported installation methods in System.Console.Hawk.PackageDbs? One thing I am concerned about is the GitHub Action .github/workflows/installation-methods.yml which detect regressions in that module by checking all the supported installation methods. Do you know if GitHub Actions support nix?

An even more transparent solution would be to let the user pass through arbitrary GHC flags, including a package DB.

I certainly wouldn't want to require users to pass a --package-db argument in order to use Hawk, as that's a fairly obscure part of ghc which cabal and stack manage to successfully hide from the user most of the time. Thus, when no such arguments are passed, hawk should still detect the package-db. But when a --package-db argument is passed, I guess hawk shouldn't detect the package-db; so that argument would have to be treated specially anyway. I thus think that supporting arbitrary GHC flags would be more complicated than just supporting a --package-db flag. Are there other GHC flags you would like to pass?

[masaeedu]

hawk makes heavy use of the hint library, and there is a hint issue explaining how to get hint working with nix. Does it help?

@gelisam Yes absolutely, thanks. After reading that issue yesterday I managed to get everything working by following the scheme of passing env vars in my Nix derivation and getting hawk to read them. My changes are kind of hacked together but you can see them here if it's of any use: main...masaeedu:bypass_package_db_detection.

I can't get to all the other points you brought up just now, but I'll circle back to this later.

[gelisam]

I stumbled upon this comment explaining how GHC_PACKAGE_PATH works. it looks like there is a special file which ghc looks for if that environment variable doesn't exist. by mimicking the way in which ghc looks for the package db, I think it should be possible to support every installation method without having to write special-case code for each.