Take into account constraints on core libs other than base.

[zenhack]

I recently had vabal fail to select a working version of ghc for a package which had base < 5, stm <2.5. I think what's happening is that it's only looking at the base requirement, but there are other libs that are pinned to a specific compiler version, so this is insufficient.

Thanks for the tool by the way; I've wanted something like this for a while.

[Franciman]

Hi, yes, that is what is happening. I can surely do it, but which packages should be considered core libs?
Because strictly speaking the only libraries that cabal considers as tied to a specific ghc version are:
base, template-haskell, ghc-prim, integer-gmp, integer-simple.
You can see it here:
https://github.com/haskell/cabal/blob/009fb61107eea05033400a4d814ceb064b570aea/cabal-install/Distribution/Solver/Modular/Solver.hs#L151

For other packages, you can also use different versions from the boot libraries coming with ghc, an example is containers.

Now, it looks like stm could be considered tied to a specific ghc version, but which other packages should be considered core (apart from base, template-haskell,ghc-prim, integer-gmp, integer-simple) ?

[zenhack]

Hm, it looks like part of the trouble actually is that stm has its own upper bound on base:

https://hackage.haskell.org/package/stm-2.4.5.1

probably "The Right Thing" here would be to solve the dependency graph ignoring the fact that those packages are pinned to the compiler, and then look at what versions of those packages it decided on. It doesn't look like cabal exposes the solver via the public API though, so that might be a tall order.

[Franciman]

The solver isn't exposed, but we could run cabal v2-configure and read the produced plan.json.
But there is an issue: to run cabal v2-configure we need to tell it which compiler version to use, and if in any of the dependencies cabal files there is an if impl(GHC) condition, the result of the configuration step depends on the compiler we have chosen when running the config and for example, say we use ghc 8.4.4 to run the configuration step, it could happen that the constraints are satisfied only by ghc 8.2.2. But! If we use ghc 8.2.2 the result of the configuration step may change :P so it's not guaranteed that ghc 8.2.2 works.
( You can read a bit more about the issues if impl(GHC) condition brings here: https://github.com/vabal/vabal/wiki/How-the-vabal-solver-works )

I had something in mind to solve this, quite a bit hacky: use vabal-lib to get the list of ghc versions compatible with the constraints, then for each ghc run cabal v2-configure, until one succedes. I also have an implementation and it's not so bad (it won't download any ghc) but it looks quite hacky.

Unfortunately for now the thing I can suggest when vabal provides an invalid ghc is to read the error that cabal outputs, and see which is the constraint it could not solve. If it's base, you can run:

vabal configure --with-base-version VER

where VER is a version you recognize can fulfill the constraints cabal had most trouble with. I've found that most of the times I can get away with this.

What do you think? I'd like to hear your feedback.

Unfortunately, for now vabal 's scope is quite narrow, because it doesn't analyse the dependencies of your package's dependencies, so any ideas to make it more useful are welcome.

[zenhack]

Quoting Francesco Magliocca (2019-01-20 19:12:58)

I had something in mind to solve this, quite a bit hacky: use vabal-lib to get the list of ghc versions compatible with the constraints, then for each ghc run cabal v2-configure, until one succedes. I also have an implementation and it's not so bad (it won't download any ghc) but it's quite hacky.

I can't think of anything better, and this doesn't seem to horrible to me. It may also make sense to open up a ticket with cabal about adding a mechanism to make this sort of thing easier.

Unfortunately for now the thing I can suggest when vabal provides an invalid ghc is to read the error that cabal outputs, and see which is the constraint it could not solve. If it's base, you can run: vabal configure --with-base-version VER where VER is a version you recognize can fulfill the constraints cabal had most trouble with. I've found that most of the times I can get away with this.

Thanks for pointing out the flag. It's not super hard to work around.

[Franciman]

Hi, after speaking to other people I've decided that I will add a flag to enable the possibility to try the various ghc versions using the cabal solver, so that a ghc that makes configuration possible can be found reilabily.
It is not going to be the default behavior for now, because I first want to see how it works in practice. So any feedback is very welcome.

[zenhack]

Sounds good.