Hi Artem, On Fri, Aug 10, 2018 at 11:05 AM Artem Pelenitsyn <a.pelenit...@gmail.com> wrote: > 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-L156 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
