I want this! It should:
The last docker point means we probably need to sync up some things.
With this command I could provide some nice Emacs support with a live hoogle search buffer, and I'd basically never have to leave Emacs to open my browser to read docs again. This closes off two big pain points for me: (1) always having to open the browser and leave my editor environment, (2) needing an internet connection to view docs. This will also basically make my whole haskell-docs package redundant which I'll be able to deprecate in favor of stack.
Pinging @manny-fp and @snoyberg for feedback/opinions.
Second thoughts, seems hoogle's -d expects a directory. So it'd probably be better as:
This has some potential for putting other databases in there, such as ones generated from your local projects, which could be neat for megarepos.
We should probably be careful about doing too much work with Hoogle 4, when I want to push forward on Hoogle 5, which changes most of this stuff quite dramatically. It's a bit of an awkward middle situation though.
I've just pushed something to Hoogle about 10 patches before the minimum-viable product, but it's enough to see where the holes are. Given Hoogle HEAD, you can do hoogle generate --local and it will use ghc-pkg to figure out which packages are installed and where there docs are, then hoogle map and it will find map or hoogle server and it will launch a server at localhost which you can search from. Clicking links will still go to the remote docs, but it is based on the local Hoogle info.
hoogle generate --local
When doing that under Stack there are 122 packages, but only 23 have docs (those shipped with GHC), because Stack doesn't include docs by default. To make stack hoogle work reasonably then stack hoogle would have to generate docs for the immediate dependencies of a module (at least), either always as it was going, or when you typed stack hoogle.
Cool! stack build --haddock (aka stack haddock) already generates docs incrementally (i.e. it will build them for dependencies that don't already have them), so doing that implicitly before stack hoogle (with an option to skip for the impatient) would probably work.
stack build --haddock
That works as a solution - it's just a shame that you have to reconfigure all the packages and that it's so slow. Also it fails on Windows, but I'm sure that's fixable: #1266.
One thing that will help with this is that we're planning to support settings defaults for build options on the configuration file. That means you could configure Stack to build haddocks for dependencies by default.
It may also be possible to implement just adding haddocks to a dependency without having to rebuild the library. I looked into this a while back and it seemed feasible, but tricky to integrate into the current build plan construction/execution pipeline.
Given things in their current state, if stack hoogle did:
stack exec -- hoogle generate --local --database=.stack-work/hoogle
stack exec -- hoogle $ARGS --database=.stack-work/hoogle
Then we'd have enough that someone could do stack hoogle filter or stack hoogle server and it would work.
stack hoogle filter
stack hoogle server
Add stack hoogle command (#55)
Implemented! Made a document here for anyone who wants to try it out: https://gist.github.com/chrisdone/78c1c1c052a853697cf3b902de086172
I tried it last night, works nicely. Any chance of a stack hoogle --server which runs stack hoogle -- --server --local? I find that a very nice way to use Hoogle via Stack.
stack hoogle --server
stack hoogle -- --server --local
@ndmitchell That makes sense to me!
@ndmitchell Made an issue here: #2310
Works perfectly for me. 👍