Automatically include dependency version constraints when generating `.cabal` files for `stack` projects

[elldritch]

This is a feature request.

I often see developers who use Stack not putting version constraints onto their dependencies since they use a specific Stack resolver version that implicitly constrains the dependency version they use.

Often, this causes breakages when attempting to cabal install their package, because Cabal will try to choose the latest packages and be unable to come up with an install plan.

For example, cabal install prune-juice (repo) fails even though stack install inside of the prune-juice repository succeeds, because Stack knows that using the lts-17.5 resolver produces a solvable install plan while Cabal does not. However, running cabal install prune-juice --constraint='aeson < 2.0.0.0' --constraint='Cabal < 3.6.0.0' does succeed, since these are the two version selections causing Cabal's install plan to break.

I see this pattern quite a bit with Stack projects. I would like hpack to automatically detect whether a project uses Stack and, if so, automatically set the versions of packages in the current Stack resolver in the Cabal file. For example, I would expect the generated prune-juice.cabal to contain e.g. Cabal == 3.2.1.0 as a dependency, having looked up the version of Cabal being used in lts-17.5 after seeing the resolver in the project's stack.yaml.

The benefit of this is that Stack projects now become cabal install-able for free, while behaving exactly the same way.

[tfausak]

For what it's worth, package authors can use the --pvp-bounds both flag when uploading packages to properly set the bounds.

https://www.fpcomplete.com/blog/2015/09/stack-pvp/ https://docs.haskellstack.org/en/stable/yaml_configuration/#pvp-bounds

[sullyj3]

For what it's worth, package authors can use the --pvp-bounds both flag when uploading packages to properly set the bounds.

From the second link:

NOTE As of Stack 1.6.0, this feature does not reliably work, due to issues with the Cabal library's printer. Stack will generate a warning when a lossy conversion occurs, in which case you may need to disable this setting. See #3550 for more information.

and in the linked stack issue https://github.com/commercialhaskell/stack/issues/3550#issuecomment-346012611

Given all of this, my recommendation is to add some comments to the release notes and documentation explaining that, due to issues with Cabal, pvp-bounds will likely not work, and recommend against using them.

Not sure what to make of all this. I don't particularly want to do it manually, so I'll probably just use --pvp-bounds both regardless and feel really unsure about it.