Can we all zoom out for a moment?
Can we turn this into a technology problem we can solve, rather than an anthropological issue?
what about adding some sort of model of "module type signature" tooling to cabal/cabal-install experimentally (and perhaps eventually GHC?).
A lot of our package version problems stem from ...... our
untyped module system. We currently don't have any static ways of reasoning / checking if two packages of modules are actually intercompatible without actually compiling them! But the information is there! Yes we need to figure out how such a design would support type classes gracefully (in a way we can all be happy with), but thats just a bullet point, not a barrier.
Theres some smart folks who've started exploring the design space in their research (its a huge design space), but perhaps we as a community should actually commit to a "k year plan, for some finite k <= 5" to actually work out typeful tooling for this recurrent library tooling pain, which requires that WE EXPERIMENT :)
seriously, lets stop focusing on the symptom, and do we what we do best, collaborate to build tools that systematically improve all of our respective approaches ('cause lets be honest, i don't think the camps here are going to change, and tribalism never helps anyone).
basically everyone's correct and wrong because its such a darn high dimensional problem that none of us have the time to correctly communicate the full nuances of the respective stances.
As always, sending an email to the libraries list when theres been this many people on the thread is a dangerous thing, but sometimes danger is my middle name.
i imagine several of you are writing up haskell module type systems papers for ICFP when not opining on this thread (not really, but I wish!)
let me start this (hopefully useful aside) with some thoughts
1) pinning package deps to a fixed version is a social construct for encoding "i want this exact set of operations with this semantics"
2) saying i want dependency P to satisfy version range ">= A && < B" is a way of saying "assuming my understanding of the range of code semantics and module types exposed over this version range is true / consistent, my code can correctly work over this range"
3) even if we had decent module types and ways of say "code works over this set of interfaces over this version range", versions and things like PVP still have value in communicating when a package is likely to be the same or different
4) cabal does need a proper SMT solver tool for handling version constraints as is, which is a totally unrelated problem, but another fun one thats actually resolvable by way of using technology
seriously, lets all zoom out of ask "how can we come up with a roadmap for evolving haskell tooling that solves the underlying need that this whole thread is indirectly about". And no it needs to be tool that doesn't pin everything to a single version, thats for APPs not LIBRARIES :)
-Carter