hoogle setup for stack hoogle is unreliable

[sjakobi]

~ $ stack hoogle Conduit
Run from outside a project, using implicit global project config
Using resolver: nightly-2016-08-06 from implicit global project's config file: /home/simon/.stack/global-project/stack.yaml
Hoogle isn't installed or is too old. Automatically installing (use --no-setup to disable) ...
Minimum version is hoogle-5.0. Found acceptable hoogle-5.0.2 in your index, installing it.
Run from outside a project, using implicit global project config
Using resolver: nightly-2016-08-06 from implicit global project's config file: /home/simon/.stack/global-project/stack.yaml

While constructing the build plan, the following exceptions were encountered:

In the dependencies for hoogle-5.0.2:
    haskell-src-exts-1.17.1 must match >=1.18 && <1.19 (latest applicable is 1.18.2)

Plan construction failed.
~ $ stack --version
Version 1.1.3, Git revision 63f203d7886801c9ec3c303db0c459f08687a3c8 (dirty) (4017 commits) x86_64 hpack-0.14.0

We should probably use the solver to find the build plan, even if that requires cabal-install.

[mgsloan]

Another option might be to have a few stack.yaml files up in some repo (stackage-content?), which specify how to build the latest hoogle atop different compilers.

[sjakobi]

to build the latest hoogle atop different compilers

Ah, thanks for pointing out that stack will build a separate hoogle binary for each project which somewhat exacerbates the problem of finding a valid build plan. Is there actually an advantage or technical need to having separate hoogle binaries as opposed to a single hoogle installation in, say, ~/.stack/programs? (Ping @chrisdone)

If only a single hoogle binary is needed we could just ask @ndmitchell to include a stack.yaml in the tarballs and use that config to build hoogle. Or we could simply pick the latest hoogle version that is included in a Stackage snapshot.

[chrisdone]

There's no technical motivation to do with LTS versions, it's just that stack build hoogle will install something for this project and not bother the global environment, which is good for IDEs. If the user wants to install the correct hoogle globally they can do so, but it's their choice.

[mhitza]

Just hit the same problem and a global install worked as an alternative.

To be honest I find it a strange choice to claim that "common" tooling should be installed per project basis. I would feel strange with an IDE that would install git for each new project I create.

On another note on hoogle, maybe others don't have this issue, but being unable to build (and sequently use) the db because the current project doesn't compile is a bit of the pain. This happens only on the first run of hoogle on the current project (and when new dependencies are added, possibly), but still I think that would be a easily second wall new users would hit (after the installation issue).

[mgsloan]

@mhitza I agree. I think we are going to have something for this in the near future - #2643