curator-2: fails on packages w/ more than 1 internal lib?

[DanBurton]

See failure: https://travis-ci.org/commercialhaskell/stackage/jobs/518547389

this-game-content (not present) depended on by:
- [ ] Allure-0.9.3.0 (-any). Mikolaj Konarski <mikolaj.konarski@funktory.com> @Mikolaj. @AllureOfTheStars. Used by: executable
- [ ] LambdaHack-0.9.3.0 (-any). Mikolaj Konarski <mikolaj.konarski@funktory.com> @Mikolaj. @LambdaHack. Used by: executable

For both of these packages, this-game-content is defined to be an internal lib in the cabal file, along with the other internal lib, this-game-src, which is notably not reported as missing. This suggests that curator-2 is only picking up the last internal lib, or some other bug like that.

http://hackage.haskell.org/package/Allure-0.9.3.0/Allure.cabal http://hackage.haskell.org/package/LambdaHack-0.9.3.0/LambdaHack.cabal

Ping @qrilka, I'm not really sure where to report curator-2 stuff.

[DanBurton]

Ping @Mikolaj

It's an unusual case, but I've chosen to constrain Allure and LambdaHack to older versions for the stackage nightly builds, for now.

No action is required on your part, but I wanted to keep you in the loop about what's going on. We'll take a look and try to fix this bug on our end.

[qrilka]

@DanBurton in principle curator-2 is now a part of Stack itself so probably it makes sense to report this in Stack tracker, regarding the issue - I think you're right and internal deps are checked only 1 level deep, I will work on fixing this

[Mikolaj]

Thank you for looking into this. For your testing, or if the problem persists, there is LambdaHack.cabal.flattened that is a version of the cabal file without internal libs. Cheers!

[Mikolaj]

BTW, I now remember I reported similar problem as a cabal issue (https://github.com/haskell/cabal/issues/created_by/Mikolaj) and I create my haddocks for Hackage using LambdaHack.cabal.flattened as a workaround.

[qrilka]

@Mikolaj dependency problem should be fixed with #4720 but I'm not sure what should we do about haddocks - we rely on package information from Hackage and Cabal+haddock to build haddocks so currently there is not option to have an alternative cabal file just for Haddocks only

[Mikolaj]

@qrilka: Understood. I will soon upload a new version to Hackage and immediately add a Hackage revision that swaps the cabal file for the flattened cabal file. That should work around the haddocks problem for the time being, until it's fixed upstream in Cabal. I will let you know so that you can permit the new versions of the packages.

Edit: Actually, I can't swap cabal file in a revision, so I will do that manually when creating the sdist archive.

[qrilka]

in that case @Mikolaj you could just create a PR removing extra constraints at https://github.com/commercialhaskell/stackage/blob/ae60748d5753e8e88495014399a96bb70372853c/build-constraints.yaml#L4537-L4539

[Mikolaj]

@qrilka: great idea. Will do. Thank you! Also, feel free to close the issue. When upstream fixes haddock, I will upload package version with original .cabal file and then, if there's any problem on your end, another issue can be openened.

[mihaimaruseac]

Internal libs are so complicated. I need to get 2-3 days with no other work and fix them once and for all. Maybe at BayHac

[Mikolaj]

@mihaimaruseac: that would be very appreciated --- the internal libs are a great way to express dependencies (or lack thereof) of groups of modules on others and they actually cut memory usage when compiling my package from ~8G to ~5G (or so, forgot actual numbers, but it matters e.g., for several old architecture debian build machines with low RAM, where currently I have to compile with -O0).

[mihaimaruseac]

I'll try to get to them as soon as possible, but I have a ton on my plate so probably won't be really able to before BayHac

[DanBurton]

(Sadly, BayHac is canceled this year.)

https://groups.google.com/forum/#!topic/bayhac/VCHrAjn1Y1U

BeachHac, perhaps? https://coday.today/about/

[mihaimaruseac]

Oh :( sorry to hear.

I'll try beachHac then