cabal configure ignores setup-depends #2614

Open
enolan opened this Issue May 28, 2015 · 8 comments

Comments

Projects
None yet
5 participants
@enolan
Contributor

enolan commented May 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
Member

23Skidoo commented May 28, 2015

@edsko

This comment has been minimized.

Show comment
Hide comment
@edsko

edsko May 28, 2015

Contributor

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

Contributor

edsko commented May 28, 2015

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

@enolan

This comment has been minimized.

Show comment
Hide comment
@enolan

enolan May 31, 2015

Contributor

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.

Contributor

enolan commented May 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@edsko

edsko May 31, 2015

Contributor

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.

Contributor

edsko commented May 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dcoutts

dcoutts Jun 1, 2015

Member

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.

Member

dcoutts commented Jun 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Jun 1, 2015

Member

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.

Member

23Skidoo commented Jun 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@edsko

edsko Jun 1, 2015

Contributor

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

Contributor

edsko commented Jun 1, 2015

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

@dcoutts

This comment has been minimized.

Show comment
Hide comment
@dcoutts

dcoutts Mar 28, 2016

Member

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.

Member

dcoutts commented Mar 28, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment