[Haskell-cafe] An Easy Solution to PVP Bounds and Cabal Hell

[Thomas Tuegel]

Hi Gershom,

On Tue, Mar 31, 2015 at 11:22 PM, Gershom B <gershomb at gmail.com> wrote:
> One way to look at a particular build is in an n-dimensional state
> space (of the Hilbert sort) determined by all its dependencies, not
> least the compiler itself. The solver acts as a particle traversing
> this space. But this description is too simple. Our state of
> dependencies and constraints itself varies and grows over time. So
> another approach is to think of the dependencies as a transitive
> graph, where each node may vary along a time axis, and as they slide
> along the axis, this in turn affects their children. We now have not
> just one Hilbert space, but a collection of them related by
> branching trees as authors locally modify the dependencies of their
> packages.

I don't know if you intended this to be a satirical remark about the
package upper bounds, but I think you really hit the nail on
the head. When we ask package authors to put upper bounds on their
dependencies, what we are really doing is asking them to propagate
information about _future_ incompatibilities back into the present. As
none of us has access to future information [1], the upper bounds on
our dependencies amount to a collection of bad guesses [2]. I think we
should consider taking a more empirical approach [3].

One way (but certainly not the only way) to approach this would be to
require packages to be uploaded to Hackage with a kind of
"build-certificate," certifying that a successful build plan was
possible given the state of Hackage at a particular timestamp. This
allows us to infer minimal upper bounds for all of the package's
transitive dependencies. Once the build-certificate is authenticated,
Hackage only needs to store the latest timestamp of a successful
build, so the overhead is very low.

In this scheme, author-specified upper bounds would be relegated to
ruling out known incompatibilities with already-released versions of
dependencies. Of course, build failures will still occur. By using
anonymous build-reporting to track the timestamp of the earliest
failed build of a package, we can automatically infer the _true_ upper
bounds on its dependencies. If contradictory reports occur, they can
be resolved by the trustees or the package's maintainers.

Just some food for thought. I hope the timing of my e-mail will not
discourage anyone from taking my suggestions seriously.

[1]. If I am mistaken and you think you do have access to future
information, please respond privately; I have some questions for you
about the stock market.

[2]. If you've never had an upper bounds problem on a package you
maintain, I'm happy for you, but there is mounting evidence that as a
community, we are very bad guessers, on average.

[3]. The PVP is orthogonal to this. It is a convenient set of
assumptions and a reasonably good set of norms; nothing more.

-- 
Thomas Tuegel