You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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 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.
@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.