4
votes

I have an older project that I created with Stack. I want to move my project to the latest LTS set from Stackage.

When I change the resolver in the stack.yaml file, the problem is that the versions in the extra-deps in the .cabal file are still for the old LTS set. Is there a way to automatically update the version numbers in the .cabal file using Stack?

1
If you're using Stack, why do you have version numbers in the cabal file at all? (I'm a haskell newb myself, so that's an actual question, not a criticism) - Chris Martin
@ChrisMartin if you want to package a project up as a library, it needs to have the proper dependency ranges in the cabal file. - sclv
I think it's fine to ship a library with unbounded dependencies in the .cabal file, as long as you ship a stack.yaml file as well.If you distribute your package through Stackage, a build server will keep compiling your project and checking for errors. That's pretty OK. (And it's not like bounding your dependencies doesn't have problems of its own.) - hao
@haoformayor shipping packages with entirely unbounded dependencies is considered very bad form. The check for errors is only against the latest stackage range. For everyone else, including people perhaps pinned to older stackage versions, the package will be nearly unusable. The policy recommended for all hackage packages is to use the package version policy. As libraries on stackage are a subset of hackage, they are no exception. - sclv
packages already become unusable; there are so many SO posts about people who can't build old packages. the whole thing, bound or stackage, is half-baked - hao

1 Answers

0
votes

You could simply delete (some of) the (upper) bounds of the build-depends in your cabal file.

When it comes to distributing your package, stack can automatically add dependency bounds if you use the --pvp-bounds flag, e.g. stack sdist --pvp-bounds upper, stack upload --pvp-bounds both etc.

There's a blog post by Michael Snoyman on this feature.