Hi Artem,
On Fri, Aug 10, 2018 at 11:05 AM Artem Pelenitsyn
The task seems to be not solvable even if an affected package (stm in your case and primitive in mine) has already adopted in its master the breaking change but has no corresponding release on Hackage (which will always be the case, because how would you release depending on base which hasn't been released yet).
Some package managers in other languages (Julia's Pkg, go install) allow you to depend directly on master branch of a package if you wish to. I wonder if there is a road here for cabal to take in order to support this kind of unsafe installs.
As a matter of fact we have a couple of options here: - Add the http://cand.hackage.haskell.org/ package index to your config and get access to the stm-2.5.0.0 package release candidate (i.e. http://hackage.haskell.org/package/stm-2.5.0.0/candidate/stm-2.5.0.0.tar.gz) - We could have added `stm-2.5.0.0` to the head.hackage overlay (so far the "overlay" has only modified existing packages from the primary hackage index) - Starting with cabal-2.4, we support adding package tarballs to `cabal.project`; and this should work also for specifiying remote tarball locations such as http://hackage.haskell.org/package/stm-2.5.0.0/candidate/stm-2.5.0.0.tar.gz - Starting with cabal 2.4, we do support remote git repo deps in `cabal.project`, see e.g. https://github.com/hvr/cardano-sl/blob/wip/cabal-project/cabal.project#L41-L... for an extensive real-world example. There's work planned to refine/improve these options and make them more convenient/expressive. Help is appreciated if somebody wants to help us get there sooner. -- hvr