Skip to content
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

Closed
johntyree opened this issue Sep 4, 2015 · 5 comments
Closed

--allow-newer for extra-deps #922

johntyree opened this issue Sep 4, 2015 · 5 comments

Comments

@johntyree
Copy link

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 in hsqml.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.

@duplode
Copy link
Contributor

duplode commented Sep 5, 2015

I don't know if the core developers would be willing to add --allow-newer; perhaps they would, as an advanced feature for non-standard workflows. In any case, such an option runs a bit counter to stack's focus on reproducible builds. With allow-newer turned on in stack.yaml, your project might build just fine in one day and then break down in the next because there was a breaking change in your extra-deps.

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 stack.yaml directly to GitHub. That has a few advantages over a local copy: other people become able to build your package without you having to bundle the extra dependency with it, and also you get a library patch ready for a pull request (which, when accepted, will make the workaround unnecessary).

@johntyree
Copy link
Author

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.

@pavelkogan
Copy link

I don't think this would impact reproducibility - the constraints in the cabal files of the extra-deps would be ignored, but the versions of their dependencies would still be fixed by stack.yaml. Since future builds would still use those exact versions, there's no risk of something changing under you.

@borsboom
Copy link
Contributor

@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.

@johntyree
Copy link
Author

👍 thanks!

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

4 participants