Is it really so hard to read that build issue? I think it is a bit verbose too, but for me it is pretty easy to boil it down to this:
cabal: Could not resolve dependencies:
numhask *test depends on doctest>=0.17 && <0.18
the only match is doctest-0.17
which depends on ghc>=7.0 && <8.11
but you are using ghc-9.0.1
Maybe cabal could give less verbose error messages like that (which would actually be constructive criticism), but I would by no means call it “wading thru constraint solver output”, which in my mind implies pages upon pages of error messages.
This is stack (from memory)
Almost there, champ! doctest upper bound just needs a slight bump.
sniff
stack has fixed versions of each package so obviously they have a much easier time giving errors: if your version bounds do not match the fixed versions, then they can just tell you to extend those bounds. You can get similar behavior (not quite as good of course) from cabal by using the stackage constraint sets for cabal, e.g.: https://www.stackage.org/lts-17.13/cabal.config, see this reddit comment and this stackage issue (admittedly this took me long to find too). But there is no stackage snapshot for GHC 9.0.1, so it wouldn’t have helped here.
No, -minimize-conflict-set didn’t help
That option only tries to make the error clearer, so if you don’t want to read any error output at all then of course it won’t help.
You say
cabal hell
This is not what people used to call “cabal hell”. Cabal hell doesn’t exist anymore with the new v2 commands that are now the default, because now every package is built in its own isolated environment.
Why do I have to say ghcid -c cabal repl
You don’t, ghcid automatically uses cabal for cabal projects. Unless you have a stack.yaml and .stack-work directory (which you would only have if you are using stack) or a .ghci file (in which case it uses ghci). My guess is that the former case applied, in which case I would suggest simply removing the .stack-work/ directory.
, and how did people expect me to find this?
It is right in the first paragraph of the “using it” section in the README:
Run
stack install ghcidorcabal update && cabal install ghcidto install it as normal. Then runghcid "--command=ghci Main.hs". The command is how you start your project in ghci. If you omit--commandthen it will default tostack ghciif you have thestack.yamlfile and.stack-workdirectory, default toghciif you have a.ghcifile in the current directory, and otherwise default tocabal repl.
I added a -v, as suggested.
The -v option is a suggestion from ghc and should be added with --ghc-options="-v" if you’re using cabal.
, and how did people expect me to find this?
It is right in the first paragraph of the “using it” section in the README:
Fair.
I added a -v, as suggested.
The -v option is a suggestion from ghc and should be added with --ghc-options="-v" if you’re using cabal.
This is an example of the general point I am making. A certain amount of information, vital to the operation of Haskell tooling and understanding of its output, exists in your head via experience (that was probably unproductive), and not in the message itself, not in our one-shot install processes, nor in defaults.
There’s certainly a stack way of doing things that I’m used to, which involves papering over some of this.
IMO, Cabal hell had little to do with v2 commands. We already had sandboxes. V2 is just smarter, automatic sandboxes (in a way).
The problem with cabal hell wasn’t a problem with cabal to begin with, but with hackage and poor workflows, sloppy releases, lack of CI etc etc. After a cabal update, there was a 50% chance that your package doesn’t build anymore. That’s on the maintainers of hackage packages, not on the cabal devs. This was “fixed” with hackage revisions, that gave hackage trustees backdoor access to package metadata… to fix all the mistakes maintainers constantly do.
These mistakes have increased since stack, because some maintainers develop against stackage sets only and don’t bother much about hackage or version bounds. That’s also not on stack, but on maintainers again.
To me that indicates: PVP and semver have failed.