Does not build with LTS-9.1

[FranklinChen]

On my Mac:

$ stack install hackage-diff --resolver lts-9.1
hackage-diff-0.1.0.1: configure
hackage-diff-0.1.0.1: build

--  While building package hackage-diff-0.1.0.1 using:
      /Users/chen/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.24.2.0 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /Users/chen/.stack/global-project/.stack-work/logs/hackage-diff-0.1.0.1.log

    Configuring hackage-diff-0.1.0.1...
    Building hackage-diff-0.1.0.1...
    Preprocessing executable 'hackage-diff' for hackage-diff-0.1.0.1...
    [1 of 1] Compiling Main             ( Main.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/hackage-diff/hackage-diff-tmp/Main.o )

    /private/var/folders/xz/z3wrll111zn03hdhkd_pxs5w0000gp/T/stack87082/hackage-diff-0.1.0.1/Main.hs:593:42: error:
        • Expecting one more argument to ‘Module’
          Expected a type, but ‘Module’ has kind ‘* -> *’
        • In the first argument of ‘Maybe’, namely ‘Module’
          In the type ‘[(String, Maybe Module)]’
          In the type declaration for ‘PackageModuleList’

[blitzcode]

No idea, that's not the set of libraries I developed & tested with. Libraries changes, newer ones might not work :/

[h4ck3rm1k3]

I have the same issue. It appears to be Language.Haskell.Exts

in ghci

Prelude Distribution.PackageDescription Distribution.ModuleName E> :t Module
Module
  :: l
     -> Maybe (ModuleHead l)
     -> [ModulePragma l]
     -> [ImportDecl l]
     -> [Decl l]
     -> Module l

[h4ck3rm1k3]

https://github.com/blitzcode/hackage-diff/pull/12 here is a first stab at this

[peti]

Ping? It would be really nice to get this issue fixed!

[blitzcode]

Why do you need it to work with a more recent snapshot, can't you just build it with the one its working with? ;-) Did LTS-4.0 & compiler bitrot to the point where you can't use it anymore on a current OS?

[peti]

Why do you need it to work with a more recent snapshot, can't you just build it with the one its working with?

Well, I can, but I don't want to. There is a difference between a build that works when I do it manually in a shell and a build process that's fully automated and integrated into my distribution. The former is fine for me, personally, but that procedure of "I build it in a shell and troubleshoot manually until it works" does not scale. It certainly does not scale for people trying to integrate this tool into a continuous integration testing environment like travis-ci, etc.

Did LTS-4.0 & compiler bitrot to the point where you can't use it anymore on a current OS?

Yes. An environment that's currently considered "old but okay" is LTS-11 and GHC 8.2.2. A "recent" environment is based on GHC 8.4.2.

There are always ways to work around this but none of them are pleasant.

[blitzcode]

The usual bitrot then. Eternal busywork is the price you pay for the privilege of using Haskell.

I updated the code to LTS 11 and fixed the build error. The build error was in one of the branches for direct parsing of Haskell code anyway, that was never a workable approach to comparing most packages (need the pre-processor defines and language options from the Cabal file for most non-trivial packages). Might as well remove it, I can't imagine its of much use for anybody.

That being said, I don't think this fix really helps much as the Hoogle DB format has kept changing and even with the fixes I did a while ago the parser still fails on many packages. I don't know if Hoogle DB has stabilized now or if the changes are documented, but that would need to fixed for the tool to become fully functional again.