-
Notifications
You must be signed in to change notification settings - Fork 696
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
Allow constraint on using installed package versions #369
Comments
(Imported comment by @Peaker on 2008-10-20) The wxcore package currently has a bug that prohibits it from being installed user-locally. This forced me to install it system-wide. When I want to install another package that depends on wxcore that is not system-wide, it thinks it should rebuild wxcore to make use of the better dependencies, and fails. In order to avoid this problem, I had to manually purge wxcore from cabal's cache/listing. It would be nice if I could ask cabal to use an already installed package rather than replace it, somehow. |
(Imported comment by @dcoutts on 2008-10-20) The root problem with wxcore is that the dependencies it ends up registering with ghc-pkg are almost unrelated to those stated in the .cabal file. So when cabal-install makes its install plan it picks deps that are different from the deps it's installed with already and so it has to rebuild it. Perhaps as a diagnostic for the custom build type, cabal should check that the registered package is actually consistent with the info in the .cabal file. |
(Imported comment by @dcoutts on 2008-10-20) Replying to @dcoutts: Perhaps as a diagnostic for the custom build type, cabal should check that the registered package is actually consistent with the info in the .cabal file. Note that this would frequently flag up packages built using franchise because it does not believe in specifying package deps. Rather it beleives in discovering required modules and at configure time discovering which packages provide those modules. |
(Imported comment by @dcoutts on 2008-10-20) This is now supported internally. We just need a way to pass the constraints in via the command line interface. I'm thinking of using: cabal install foo --constraint="bar installed"which mirrors the existing: cabal install foo --constraint="bar >= 1.2"and similarly we could add flags constraints for particular packages: cabal install foo --constraint="bar +gtk -vty"but perhaps flags want a different approach. Suggestions welcome. |
(Imported comment by @kosmikus on 2008-12-19) This is fixed in the HEAD. |
It would be nice if |
@andreasabel sounds like a reasonable ask. I'd expect that a new issue (maybe referencing this one) would be a more effective way forward. |
(Imported from Trac #376, reported by @dcoutts on 2008-10-20)
We allow command line args for adding version constraints. Internally the dependency resolver can use constraints on the installed status. We should allow such constraints to be given on the command line, and possibly in the cabal config file.
We should probably also allow preferences to be given on the command line too.
The text was updated successfully, but these errors were encountered: