Hoogle version check failure

[AlexeyRaga]

With each new version of hoogle there is this kind of an error:

Using hoogle db at: /Users/user/code/Haskell/stack/turtle/.stack-work/hoogle/x86_64-osx/nightly-2017-12-15/8.2.2/database.hoo
hie: The Hoogle file /Users/user/code/Haskell/stack/turtle/.stack-work/hoogle/x86_64-osx/nightly-2017-12-15/8.2.2/database.hoo is the wrong version or format.
Expected: HOOGLE-5.0.16
Got     : HOOGLE-5.0.14
CallStack (from HasCallStack):
  error, called at src/General/Store.hs:177:13 in hoogle-5.0.16-9nJOEzrw9JECpz50DooZQ3:General.Store
CallStack (from HasCallStack):
  error, called at src/General/Util.hs:235:66 in hoogle-5.0.16-9nJOEzrw9JECpz50DooZQ3:General.Util

I checked the source and it says

if verString /= verStart then
            error $ "The Hoogle file " ++ file ++ " is the wrong version or format.\n" ++
            ...

This gets especially bad when hoogle is used as a library by other tools, such as haskell-ide-engine. It is bad because currently it is required to make sure that all the different tools and the hoogle itself are using the same version, so when I build the documentation everything can still read it.

The issue can be avoided if instead of doing a version check hoogle would do, for example, a file format check. Or if it kept a format version in the file and check that instead of a tool version itself. I hope that the format doesn't change as often as hoogle itself, and when it does then it could probably be a major version bump, or even some backwards compatibility with one prev. version?

[ndmitchell]

I'm happy enough to say that I always bump the 0.1 when doing a file format change OR a API change - does that sound a reasonable approach?

However, you're still going to need to upgrade Hoogle databases sometimes, so I wonder if there's any way you could make it seamless when an upgrade happens? My concern is you're going to move from something painful happening semi-regularly to something painful happening rarely - at which point no one can remember how to recover.

[ndmitchell]

I also note that as soon as I make this change, it's going to break all on-disk databases...

[AlexeyRaga]

If a file format version change is always reflected in a major version number, then maybe we can avoid breaking all the existing databases by just updating the check itself to something like if (major ver) /= (major dbVer)

I understand sem-regular breakages and pain, and I don't have a good solution in mind rather than supporting backwards compatibility of some sort :(

[ndmitchell]

I've changed the code to make it only worry about the first 3 version components, and the next release will be 5.0.17.1 so won't break the version numbering.

What process is currently used to generate the files? Couldn't you rerun that process when the database format changes?

[AlexeyRaga]

The database is generated by hoogle generate or by stack hoogle. But the result database is then consumed by haskell-ide-engine which may not be linked with the same version of hoogle that user have installed.

So we have two options here, really:

• Re-compile haskell-ide-engine with the same version of hoogle
• Re-install hoogle so it is the same version that haskell-ide-engine expects.

I just wanted to relax this coupling a bit, or to make versions mismatch less frequent.

Thanks for the change!

[ndmitchell]

Reducing the coupling seems useful anyway, but if hoogle-ide-engine is using the database, couldn't it generate it itself? That way you'd get guaranteed matching in all circumstances.

[AlexeyRaga]

This is exactly what I am discussing here: https://github.com/haskell/haskell-ide-engine/issues/452 :)