Disables fast-digits due to unsupported Cabal features

[jkachmar]

fast-digits-0.3.1.0 was released recently, and it leverages the multiple internal libraries feature that was introduced in Cabal 3.

Unfortunately stack (and by extension Stackage) don't seem to support this feature at the moment, so this breaks the Stackage Nightly build.

cc @Bodigrim to let you know; I'm not sure what the resolution on our side is for this, but it does seem unfortunate that this is unsupported at the moment.

[Bodigrim]

@jkachmar sorry, I'm AFK. Would it be alright if I get back to you next week?

I must have been daydreaming, but somehow I was absolutely confident that Stack can handle this feature. Sorry for this. (It is not Cabal 3 btw, it's available since Cabal 2)

[jkachmar]

Ah, my mistake; I must have been confusing that with the multiple public libraries feature 😅.

I've temporarily disabled the package so this isn't blocking anything; we can just re-enable it whenever you get a chance to make the change.

If you're not opposed to it, I could try making a PR reverting fast-digits back to the original structure if I have the time this weekend.

[juhp]

Could we not revert to the older version of fast-digits in the meantime in Nightly?

[Bodigrim]

@jkachmar I'm confused; are you sure that multiple internal libraries are unsupported? I've just checked and it seems that Stack handles them just fine:

stack unpack fast-digits-0.3.1.0
cd fast-digits-0.3.1.0
stack init # lts-18.5
stack test

This succeeds with Test suite fast-digits-tests passed. Completed 2 action(s) on my machine.

$ stack --version
Version 2.5.1, Git revision d6ab861544918185236cf826cb2028abb266d6d5 x86_64 hpack-0.33.0

[Bodigrim]

After reading through commercialhaskell/stack#4564, it appears that stack build && stack repl succeeds, but rm -rf .stack-work && stack repl does fail with cannot satisfy -package z-fast-digits-z-fast-digits-internal. So it's not like Stack does not support internal libraries in general (in this case I'd expect a decent error message even for stack build), but more like certain aspects of Stack support for internal libraries are buggy.

As much as I'd like to be tool-agnostic, I'm reluctant to make an additional release just to work around a bug in a build tool. I'm happy to review this, if in future Stack team takes a stance that internal libraries won't be supported and adds a specific error message.

I'm not sure why the issue with stack repl concerns Stackage, but if it is a blocker please pin fast-digits to 0.3.0.0.

[bergmark]

@jkachmar do you remember what the build log said?

[jkachmar]

Fortunately Jens dropped the output in Slack.

build log

singleBuild: invariant violated: multiple results when describing installed package (PackageName "z-fast-digits-z-fast-digits-internal",[DumpPackage {dpGhcPkgId = "fast-digits-0.3.1.0-CyaVm8JAPRtEiuSJGJCPui-fast-digits-internal", dpPackageIdent = PackageIdentifier {pkgName = PackageName "z-fast-digits-z-fast-digits-internal", pkgVersion = mkVersion [0,3,1,0]}, dpParentLibIdent = Just (PackageIdentifier {pkgName = PackageName "fast-digits", pkgVersion = mkVersion [0,3,1,0]}), dpLicense = Just (GPL (Just (mkVersion [3,0]))), dpLibDirs = ["/var/stackage/work/unpack-dir/.stack-work/install/x86_64-linux/1ecc1ccde102e7e24c66d5576487b526358527fde0c10fb4dad4ca9e23f99a77/9.0.1/lib/x86_64-linux-ghc-9.0.1/fast-digits-0.3.1.0-CyaVm8JAPRtEiuSJGJCPui-fast-digits-internal"], dpLibraries = ["HSfast-digits-0.3.1.0-CyaVm8JAPRtEiuSJGJCPui-fast-digits-internal"], dpHasExposedModules = True, dpExposedModules = fromList [ModuleName ["Data","FastDigits","Internal"]], dpDepends = ["base-4.15.0.0"], dpHaddockInterfaces = ["/var/stackage/work/unpack-dir/.stack-work/install/x86_64-linux/1ecc1ccde102e7e24c66d5576487b526358527fde0c10fb4dad4ca9e23f99a77/9.0.1/doc/fast-digits-0.3.1.0/fast-digits.haddock"], dpHaddockHtml = Just "/var/stackage/work/unpack-dir/.stack-work/install/x86_64-linux/1ecc1ccde102e7e24c66d5576487b526358527fde0c10fb4dad4ca9e23f99a77/9.0.1/doc/fast-digits-0.3.1.0", dpIsExposed = False},DumpPackage {dpGhcPkgId = "fast-digits-0.3.0.0-ATnOwdOu935CfteJIQqzt8-fast-digits-internal", dpPackageIdent = PackageIdentifier {pkgName = PackageName "z-fast-digits-z-fast-digits-internal", pkgVersion = mkVersion [0,3,0,0]}, dpParentLibIdent = Just (PackageIdentifier {pkgName = PackageName "fast-digits", pkgVersion = mkVersion [0,3,0,0]}), dpLicense = Just (GPL (Just (mkVersion [3,0]))), dpLibDirs = ["/var/stackage/work/unpack-dir/.stack-work/install/x86_64-linux/1ecc1ccde102e7e24c66d5576487b526358527fde0c10fb4dad4ca9e23f99a77/9.0.1/lib/x86_64-linux-ghc-9.0.1/fast-digits-0.3.0.0-ATnOwdOu935CfteJIQqzt8-fast-digits-internal"], dpLibraries = ["HSfast-digits-0.3.0.0-ATnOwdOu935CfteJIQqzt8-fast-digits-internal"], dpHasExposedModules = True, dpExposedModules = fromList [ModuleName ["Data","FastDigits","Internal"]], dpDepends = ["base-4.15.0.0","integer-gmp-1.1"], dpHaddockInterfaces = ["/var/stackage/work/unpack-dir/.stack-work/install/x86_64-linux/1ecc1ccde102e7e24c66d5576487b526358527fde0c10fb4dad4ca9e23f99a77/9.0.1/doc/fast-digits-0.3.0.0/fast-digits.haddock"], dpHaddockHtml = Just "/var/stackage/work/unpack-dir/.stack-work/install/x86_64-linux/1ecc1ccde102e7e24c66d5576487b526358527fde0c10fb4dad4ca9e23f99a77/9.0.1/doc/fast-digits-0.3.0.0", dpIsExposed = False}])

I suppose this is just a curator issue then, not a general stack issue?

[jkachmar]

Looks like I was wrong here, however that doesn't help me understand how to resolve this any better.

I restricted the LTS 18.6 build to fast-digits-0.3.0.0 and it's failing despite the fact that we did successfully build it when pushing out LTS 18.5 & the earlier nightlies.

I'm at a bit of a loss in terms of understanding how this worked before but seems to be failing now; I'll forward this along to some of the other curators and hopefully someone will have an idea about how to proceed.

[Bodigrim]

Right, fast-digits-0.3.0.0, while being present in LTS 18.5, contains an internal library as well: https://github.com/Bodigrim/fast-digits/blob/9ec06f1fb925c16ce89ad83a66e6f706b469bfe4/fast-digits.cabal

[jkachmar]

Okay I've done a bit more digging and it looks like this error comes from the following block of code in stack:

https://github.com/commercialhaskell/stack/blob/99109189f813584f98111e3d92c353c7421d0478/src/Stack/Build/Execute.hs#L1752-L1760

...and the issue we're seeing is one that's happened before as well: commercialhaskell/stack#5264.

Unfortunately I'm not aware of a path forward besides disabling fast-digits, and more frustratingly I don't understand why fast-digits-0.3.0.0 previously worked and is now failing on both nightly and the LTS.

cc @snoyberg on this because you're the only person I can think of who might have the context around how to resolve this sort of issue.

[snoyberg]

if in future Stack team takes a stance that internal libraries won't be supported and adds a specific error message

For the record, this is my personal preference. I was opposed to these new features in Cabal from the start and had all objections overridden. It's difficult playing with the Cabal treadmill when features are flung downstream. So yes, my personal preference would be removing usage of these features.

That said, others did implement the support for these internal libraries. It's been a constant source of bugs. I don't think I'll be implementing my own bug fixes here, since this isn't a feature I want to waste more time on.

For workarounds: typically in this situation my workaround is to manually unregister things from the GHC package database. I'm not sure if you've tried that already @jkachmar. I can hop onto the build server and try to resuscitate this if you'd like.

[bergmark]

This needs features in stack, and is tracked by commercialhaskell/stack#5318