rejecting: QuickCheck-2.15.0.1/installed-e799c2af (package is broken, missing dependency rndm-1.2.1.3-0bdccfc1

[GeorgeCo]

Describe the bug

$ cabal install --lib codeworld-api
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.14.1.0 supports
'ghc' version < 9.12): /usr/local/bin/ghc is version 9.12.1
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.14.1.0 supports
'ghc' version < 9.12): /usr/local/bin/ghc is version 9.12.1
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] next goal: QuickCheck (user goal)
[__0] rejecting: QuickCheck-2.15.0.1/installed-e799c2af (package is broken, missing dependency rndm-1.2.1.3-0bdccfc1)

To Reproduce

• install cabal 3.14.10
• install ghc 9.12.1

$ cabal install hlint
$ cabal install --lib mwc-random
$ cabal install --lib codeworld-api

Expected behavior

No broken packages or missing dependencies.

System information

MacOS 15.3.1 (Apple Silicon)

$  cabal --version
cabal-install version 3.14.1.0
compiled using version 3.14.1.0 of the Cabal library 

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.12.1

$ ls -R /Users/gcolpitts/.cabal/store/ghc-9.12.1-623c/rndm*
cabal-hash.txt	lib		share

/Users/gcolpitts/.cabal/store/ghc-9.12.1-623c/rndm-1.2.1.3-0bdccfc1/lib:
System				libHSrndm-1.2.1.3-0bdccfc1.a

/Users/gcolpitts/.cabal/store/ghc-9.12.1-623c/rndm-1.2.1.3-0bdccfc1/lib/System:
Random		Random.dyn_hi	Random.hi

/Users/gcolpitts/.cabal/store/ghc-9.12.1-623c/rndm-1.2.1.3-0bdccfc1/lib/System/Random:
GFinite.dyn_hi	GFinite.hi	Internal.dyn_hi	Internal.hi	Stateful.dyn_hi	Stateful.hi

/Users/gcolpitts/.cabal/store/ghc-9.12.1-623c/rndm-1.2.1.3-0bdccfc1/share:
doc

/Users/gcolpitts/.cabal/store/ghc-9.12.1-623c/rndm-1.2.1.3-0bdccfc1/share/doc:
LICENSE

[ulysses4ever]

Are you doing cabal install --lib in a project directory?

[GeorgeCo]

No. Is there documentation that says I should? This used to work reliably. It started to be less reliable with cabal v2. I like to write and run a single file of haskell code. A project seems like overkill.

[ulysses4ever]

No, you should not, I'm just trying to figure out the context.

For single-file program you'd be better off using scripts (see online documentation for cabal run). Otoh, cabal install --lib is highly experimental.

[GeorgeCo]

Thanks for the quick response! The doc isn't clear but I assume cabal scripts aren't compiled, i.e. they run interpreted. That can be 50 times or more slower than compiled code as I'm sure you know. I've been using cabal install --lib for over a decade and have never considered it experimental. BTW what is the URL for the cabal 3.14.1 doc? All I could find is the 3.12.1 doc at https://cabal.readthedocs.io/en/stable/

[ulysses4ever]

The doc isn't clear but I assume cabal scripts aren't compiled, i.e. they run interpreted. That can be 50 times or more slower than compiled code as I'm sure you know.

Not at all. It's built normally, to an executable.

I've been using cabal install --lib for over a decade and have never considered it experimental.

For a long time it even had a warning about it being experimental. I wish we didn't remove it... But that's not an actionable piece of an advice.

BTW what is the URL for the cabal 3.14.1 doc? All I could find is the 3.12.1 doc at cabal.readthedocs.io/en/stable

read-the-docs is a bit confusing about it indeed. And also it's confused about 3.14 for some reason in that it doesn't selects it by default I think. You can switch versions using the little menu in the dark selector saying "stable", positioned in the right-bottom corner of the page.

Another shot in the dark

Could you try to run a variant of your reproducer:

$ cd $(mktemp -d)
$ cabal install --lib --package-env=. mwc-random
$ cabal install --lib --package-env=. codeworld-api

(hlint shouldn't matter, I hope)

I tried to reproduce it myself, but I had to add --allow-newer and after that the build failed with an error that looks like it's a version mismatch:

[47 of 50] Compiling Network.HTTP2.Server.Worker ( Network/HTTP2/Server/Worker.hs, dist/build/Network/HTTP2/Server/Worker.o, dist/build/Network/HTTP2/Server/Worker.dyn_o )
Network/HTTP2/Server/Worker.hs:118:68: error: [GHC-83865]
    • Couldn't match expected type ‘Sentinel’ with actual type ‘IO ()’
    • In the fourth argument of ‘fillFileBodyGetNext’, namely ‘refresh’
      In the expression:
        fillFileBodyGetNext pread fileoff bytecount refresh
      In an equation for ‘next’:
          next = fillFileBodyGetNext pread fileoff bytecount refresh
    |
118 |             let next = fillFileBodyGetNext pread fileoff bytecount refresh
    |                                                                    ^^^^^^^

Error: [Cabal-7125]
Failed to build http2-5.3.4 (which is required by codeworld-api-0.8.1). See the build log above for details.

[Bodigrim]

Given that @GeorgeCo is able to compile codeworld-api with GHC 9.12, there must be allow-newer: True somewhere. Probably two invocations of cabal install --lib ended up building QuickCheck against different versions of random. But isn't it something to expect about cabal install? You might be lucky for some time not to install conflicting dependency trees, but eventually it will happen, no?..

@GeorgeCo I'd strongly suggest to start migration to cabal run for single-file scripts: https://cabal.readthedocs.io/en/3.14/getting-started.html#running-a-single-file-haskell-script

[GeorgeCo]

@Bodigrim I wasn't able to compile codeworld-api. I don't understand why you thought I could.

wrt single-file scripts , couldn't the compiler or another tool infer what is in the cabal comment and just compile the file for the user without the user having to figure out the appropriate cabal comment?

I haven't migrated to cabal run for single file scripts as I have already have enough to learn in Haskell without learning cabal. To understand what to put in the comment I have to read the whole cabal manual to figure out what I need to put in that comment.

Also does each single file script have to be in its own directory or can I have several in one directory?

I don't think I ended up building QuickCheck against different versions of random but I will try to reproduce the problem using @ulysses4ever instructions and see if I did.

I've used packages in Python, pip3 seems similar to cabal. I install packages with pip3. I can use them in code with just an import statement. This is similar to the way I use cabal and Haskell. Why can't Haskell be as simple as Python?

My use case is similar to the one described by Richard Eisenberg in #7832:

Use case
I would like to experiment with ... a few library functions. I am not building software to ship. I am just trying to learn more about Haskell. So I'd like to be able, say, to build an executable that depends on a few packages without needing to edit a .cabal file every time I change the set of dependencies. (Remember: the goal is quick experimentation!)

Gabaz writes in that bug:

we do have on our roadmap fixing the actual issue highlighted here, and more generally reworking the ergonomics and UI of cabal install to make managing environments actually straightforward for users. Further, we do think the use case Richard has outlined of a "nice universe for a playground" is an important one.

Richard replied:

Further, we do think the use case Richard has outlined of a "nice universe for a playground" is an important one.

Great -- glad to hear it. Thank you.

However, experience has repeatedly shown that "do what I mean" algos in package management lead to frustrated and confused users, and while things should be as easy as possible, they should also be no easier than that, and finding that balance is not going to be simple.

I agree here, and have not thought about the specific of the algorithms above. But, there is an algorithm that is known to (mostly) work: what v1 did. That is, the universe expands only by user request, when that user asks to add a new package to their universe. At that point, cabal selects the most recent release of that package (or whatever version the user asked for). Then, cabal uses the same algorithm it usually uses to decide its dependencies. This worked for the lifetime of v1. But it only mostly worked, because of cabal-hell: that's why v2 exists! So there would be a potential pitfall in that users try to build an inconsistent universe, or they build a consistent universe that doesn't serve their actual needs. I'm not sure those pitfalls are avoidable... but maybe they could be mitigated with cabal destroy-universe which blows away the current universe, allowing the user to re-expand it from scratch. (In my own practice, a universe went stale at about the same rate as GHC released, and so I just moved to a new GHC when things got rough in the universe.)

It seems that this issue, a "nice universe for a playground" , is still alive but the current state of cabal install --lib and potential pitfalls are not documented. I think that doing so is important. I don't really understand the history of cabal install --lib. It appears supported but everybody says not to use it.

As cabal install --lib is supported I'd like to resolve whether or not I've found a bug. Next I have to try cabal run and single file scripts and possibly file some doc enhancement requests for that (e.g. the simple example in the bug doesn't show how to specify to compile with -O)

[Bodigrim]

@Bodigrim I wasn't able to compile codeworld-api. I don't understand why you thought I could.

You were able at least to start compiling it despite its version bounds clearly prohibiting GHC 9.12. So something in your environment sets allow-newer: True or similar. Do you know what it is? Anything interesting in your ~/.cabal/config? Unless we figure this out, the issue is not easily reproducible.

Also does each single file script have to be in its own directory or can I have several in one directory?

You can have several in one directory.

[GeorgeCo]

Thanks for your help. Can no longer reproduce:

cabal install --lib codeworld-api
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.14.1.0 supports
'ghc' version < 9.12): /usr/local/bin/ghc is version 9.12.1
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.14.1.0 supports
'ghc' version < 9.12): /usr/local/bin/ghc is version 9.12.1
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: base-4.21.0.0/installed-071b (user goal)
[__1] trying: bytestring-0.12.2.0/installed-e50b (user goal)
[__2] next goal: codeworld-api (user goal)
[__2] rejecting: codeworld-api-0.8.1 (conflict: bytestring==0.12.2.0/installed-e50b, codeworld-api => bytestring>=0.9 && <0.12)
[__2] skipping: codeworld-api; 0.8.0, 0.7.0, 0.6.0, 0.5.0, 0.4.0 (has the same characteristics that caused the previous version to fail: excludes 'bytestring' version 0.12.2.0)
[__2] rejecting: codeworld-api; 0.3.1, 0.3, 0.2.5 (conflict: base => ghc-prim==0.13.0/installed-e656, codeworld-api => ghc-prim>=0.3.1 && <0.6)
[__2] trying: codeworld-api-0.2.4
[__3] next goal: time (dependency of codeworld-api)
[__3] rejecting: time-1.14/installed-6c95 (conflict: codeworld-api => time>=1.6.0 && <1.9)
[__3] skipping: time; 1.14, 1.12.2, 1.12.1, 1.12, 1.11.1.2, 1.11.1.1, 1.11.1, 1.11, 1.10, 1.9.3, 1.9.2, 1.9.1, 1.9 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=1.6.0 && <1.9' from 'codeworld-api')
[__3] rejecting: time-1.8.0.4 (conflict: base==4.21.0.0/installed-071b, time => base>=4.7 && <4.13)
[__3] skipping: time; 1.8.0.3, 1.8.0.2, 1.8.0.1, 1.8, 1.7.0.1, 1.7, 1.6.0.1, 1.6, 1.5.0.1 (has the same characteristics that caused the previous version to fail: excludes 'base' version 4.21.0.0)
[__3] rejecting: time-1.5 (conflict: codeworld-api => time>=1.6.0 && <1.9)
[__3] skipping: time; 1.4.2, 1.4.1, 1.4.0.2, 1.4.0.1, 1.4, 1.3, 1.2.0.5, 1.2.0.4, 1.2.0.3, 1.2.0.2, 1.2.0.1, 1.2, 1.1.4, 1.1.3, 1.1.2.4, 1.1.2.3, 1.1.2.2, 1.1.2.1, 1.1.2.0, 1.0, 1.13 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=1.6.0 && <1.9' from 'codeworld-api')
[__3] fail (backjumping, conflict set: base, codeworld-api, time)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: bytestring, codeworld-api, base, time
Try running with --minimize-conflict-set to improve the error message.