[Haskell-cafe] Cabal hell

[Michal Antkiewicz]

Well if the package X you depend on adheres to PVP [1]

then you depend on it like this to allow newer minor versions:

x == A.B.*

where

"*A.B* is known as the *major* version number, and *C* the *minor* version
number."

If only every package maintainer adhered to this, we'd be in much better
shape.

Michal

[1] https://wiki.haskell.org/Package_versioning_policy

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 [1].
>
> 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
> compatible.
>
> 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.
>
> [1] https://wiki.qt.io/Qt-Version-Compatibility
>
> On Thu, Apr 9, 2015 at 7:44 PM, Patrick Redmond <plredmond at gmail.com>
> wrote:
>
>> 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 [1], 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
>> composability.
>>
>> 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?
>>
>> [1] http://f06code.com/post/90205977959/cabal-usage-notes
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150409/5c4f1412/attachment.html>