[Haskell-cafe] Cabal hell
mantkiew at gsd.uwaterloo.ca
Thu Apr 9 17:28:01 UTC 2015
Well if the package X you depend on adheres to PVP 
then you depend on it like this to allow newer minor versions:
x == A.B.*
"*A.B* is known as the *major* version number, and *C* the *minor* version
If only every package maintainer adhered to this, we'd be in much better
On Thu, Apr 9, 2015 at 1:24 PM, Alexey Shmalko <rasen.dubi at gmail.com> wrote:
> I really love Qt versioning scheme when applied to compatibility .
> Given version is Major.Minor.Patch:
> Major releases may break backwards binary and source compatibility,
> although source compatibility may be maintained.
> Minor releases are backwards binary and source compatible.
> Patch releases are both backwards and forwards binary and source
> So that you know your package will work with any Qt version that has the
> same major version and minor version is greater-equal to the one you
> developed your package with. It would be really great if everyone followed
> this scheme.
> As a drawback I can note that this requires strict discipline from a
> library developer. It's also harder to get binary compatibility right for
> Haskell because of cross-module optimization GHC does.
>  https://wiki.qt.io/Qt-Version-Compatibility
> On Thu, Apr 9, 2015 at 7:44 PM, Patrick Redmond <plredmond at gmail.com>
>> Since learning Haskell I've had the pleasure of finding my way out of a
>> cabal hell or two. I've developed some knowledge to cope with it , but
>> mostly concluded that if I can avoid burdening my projects
>> with dependencies that have many of their own dependencies, then cabal hell
>> can be averted. This puts somewhat of a damper on the joy of haskell's
>> With the new release of GHC I've observed a flurry of discussion on
>> haskell mailing lists and from Linux distro maintainers about all the
>> fixing and patching required to keep the haskell ecosystem going.
>> Meanwhile I've learned other languages and used other tools that don't
>> seem to have this problem that haskell does. For example, in the elm-lang
>> community the package management tool enforces strict api-versioning, and
>> in the clojure ecosystem people talk about "repeatability" and achieve it
>> by using mostly exact-version requirements, even including the language
>> (the language version is a dependency of a project, rather than a
>> constraint of the environment).
>> I guess I'm wondering why we don't try something simpler to solve the
>> haskell cabal hell problem. How about using minimum version dependencies
>> only, not ranges, since we can't accurately guess about the future
>> compatibility of our projects. How about automatic api-versioning of our
>> projects to give the version numbers some rigid semantics with regard to
>> package compatibility?
>>  http://f06code.com/post/90205977959/cabal-usage-notes
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe