-
Notifications
You must be signed in to change notification settings - Fork 841
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-newer for extra-deps #922
Comments
I don't know if the core developers would be willing to add P.S.: When I ran into the issue you describe, my workaround was similar, except that I bumped the dependency constraints in my GitHub fork of the library and then pointed |
The Github workaround + patch is nice assuming the original project is on Github. I suppose what this really implies is a one-time to avoid changing resolvers. I can live with your forking solution for now. |
I don't think this would impact reproducibility - the constraints in the cabal files of the |
@pavelkogan: Thanks for clarifying that, because from the original description I also thought you meant it would be able to change the dependencies out from under you. Anyway, sounds like this would be a handy feature, and a PR would be welcome. |
👍 thanks! |
I have a little application that makes use of the
hsqml
library. This library hasn't been updated too recently, and so has dependency constraints that exclude the current stack LTS version. I worked around it by using a local copy of the library and manually editing the constraints inhsqml.cabal
and verifying that everything still worked as expected.It appears that
cabal-install
supports an--allow-newer
flag to support just this use case. Does stack? I could not find it in the "in-depth guide" (which is great!) or the stack.yaml wiki page.If it isn't supported, could it? What would be necessary for this? I'd be willing to work on it.
The text was updated successfully, but these errors were encountered: