hackage-diff
hackage-diff copied to clipboard
Does not build with LTS-9.1
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’
No idea, that's not the set of libraries I developed & tested with. Libraries changes, newer ones might not work :/
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
https://github.com/blitzcode/hackage-diff/pull/12 here is a first stab at this
Ping? It would be really nice to get this issue fixed!
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?
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.
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.