cabal configure ignores setup-depends

[enolan]

I've set up a test case at https://github.com/enolan/cabal-custom-setup-test. It contains a simple project with the following setup-depends section:

custom-setup
  setup-depends:      base, Cabal, shake

And its Setup.hs imports the Development.Shake module. Running cabal configure with HEAD cabal and cabal-install results in this:

dist/setup/setup.hs:2:8:
    Could not find module ‘Development.Shake’
    Use -v to see a list of the files searched for.

The shake package is not downloaded or built.
The setup.sh file grabs cabal from git, creates a sandbox with existing cabal-install, adds Cabal and cabal-install as sources, builds the new cabal-install in the sandbox, and uses it to run cabal configure.

[23Skidoo]

/cc @edsko, @dcoutts

[edsko]

I wonder if it's using the right version of Cabal to actually configure? See #2540 (comment) for a possibly comparable problem.

[enolan]

I looked into this a bit further. It turns out cabal configure attempts to make a build plan, and if it fails, prints a warning that only shows up with -v and build the Setup.hs anyway.

:<

I'd expect it to just fail with an error message, but I don't know the original rationale. I can't think of a situation where you'd want the configure script when the project isn't buildable.

[edsko]

Ah. I changed that actually so that that would be an error, but there is a good if somewhat convoluted reason for this. Pinging @dcoutts for details.

[dcoutts]

Historically we could not always require that we must find a consistent configuration at the cabal configure step, because people were used to using Setup.hs configure where that degree of consistency was not required and while such cases were not guaranteed to work, they didn't always fail, so we didn't feel able at the time to exclude them.

Now that hardly anyone develops using Setup.hs configure anymore, and are used to cabal install requiring consistent build plans, I think we're probably safe for us to drop the compatibility behaviour and always require a consistent build plan at configure time.

It means that it will become impossible to cabal configure a package that indirectly depends on two versions of some dep, even when such a configuration might actually work.

So summary: yes I think we can now drop the fallback and fail hard if the solver doesn't find a solution there.

[23Skidoo]

So summary: yes I think we can now drop the fallback and fail hard if the solver doesn't find a solution there.

We actually did that once already, but it broke the containers test suite (due to #1575), so the patch was reverted. Now with qualified goals implemented it should be possible to fix this the right way.

[edsko]

Ah, yes. I knew there was a reason we couldn't fix this just yet.

[dcoutts]

Note that the nix-local-build branch doesn't use a fallback, and on cabal configure or build would do the right thing for this case.