Any ways to test a GHC build against large set of packages (including test suites)?

[Herbert Valerio Riedel]

Hi Artem,

On Fri, Aug 10, 2018 at 11:05 AM Artem Pelenitsyn
<a.pelenitsyn at 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