Skip to content

custom-setup solving problem, is Cabal version shared across all Setup.hs? #4295

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
phadej opened this issue Feb 5, 2017 · 7 comments
Closed

Comments

@phadej
Copy link
Collaborator

phadej commented Feb 5, 2017

Happens only with GHC 7.8.4 and older.

With the code in ulidtko/cabal-doctest@742c2d0
Only if I add a cabal-doctests >=1.0.1 bound to example.cabal's setup-depends, I'll get a solver error https://travis-ci.org/phadej/cabal-doctest/jobs/198593113

This is very unfortunate, as I don't see why there can't be valid plan (Cabal for ComponentSetup should interfere with ghc / doctest etc part of the --enable-tests plan)

example:setup.Cabal-1.2.1, example:setup.Cabal-1.1.6 (constraint from minimum
version of Cabal used by Setup.hs requires >=1.20)
rejecting: example:setup.Cabal-1.24.1.0 (dependencies not linked: cannot make
example:setup.Cabal canonical member of
{*Cabal-1.18.1.5/installed-647...,example:setup.Cabal-1.18.1.5/installed-647...};
conflict set: Cabal, example:setup.Cabal, example:setup.cabal-doctest)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: example:setup.Cabal (6609),
example:setup.cabal-doctest (6567), Cabal (3617), doctest (3451),
example-1:test (3447), example (2798), example:setup.base (1432),

@phadej
Copy link
Collaborator Author

phadej commented Feb 5, 2017

cc @grayjay

@phadej
Copy link
Collaborator Author

phadej commented Feb 5, 2017

I have no idea where from the Cabal >= 1.20 bound comes from. Feel free to ask me on IRC for more details.

@ezyang
Copy link
Contributor

ezyang commented Feb 5, 2017

new-build requires 1.20 or later because 1.18 setup does not support --dependency, so it's not possible for us to request specific packages. 80de7ff and #4051.

We should make "minimum
version of Cabal used by Setup.hs requires >=1.20" clearer by referencing an actual ticket number; if you grep you'll see where it comes from.

@grayjay
Copy link
Collaborator

grayjay commented Feb 5, 2017

The problem is that new-build adds all packages from cabal.project to the list of targets for the dependency solver, so they all are required to have consistent dependencies. In this example, the solver would ideally choose the installed Cabal for example's doctests test suite and a newer Cabal for example's setup script. The test suite needs the installed Cabal, because it depends on doctest, which depends on the installed ghc package, and ghc depends on Cabal. However, the two Cabal dependencies are forced to be the same instance because the setup script also depends on cabal-doctest and cabal-doctest is a top-level build target.

One solution is to enable --independent-goals for new-build. Then some packages in a project can be setup dependencies for others and be allowed to have different versions for their dependencies.

/cc @dcoutts

@phadej
Copy link
Collaborator Author

phadej commented Feb 6, 2017

@grayjay thanks for the explanation!

@ezyang
Copy link
Contributor

ezyang commented Feb 7, 2017

Note that the --independent-goals flag is currently disabled.

grayjay added a commit to grayjay/cabal that referenced this issue May 1, 2017
grayjay added a commit to grayjay/cabal that referenced this issue May 1, 2017
--independent-goals could be useful for using local packages as setup or
build-tool dependencies in new-build.  See haskell#4295 for an example of a dependency
problem that requires --independent-goals.  The flag is off by default.
grayjay added a commit to grayjay/cabal that referenced this issue May 1, 2017
@grayjay
Copy link
Collaborator

grayjay commented Dec 23, 2019

I think the issue with building cabal-doctest was resolved with the --independent-goals flag. I opened a separate issue for enabling the flag by default: #6460

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

No branches or pull requests

3 participants