[Haskell-cafe] Cabal hell

[Michal Antkiewicz]

Yes, there was a proposal to follow how it's done in Elm: Cabal PVP
compliance checker [1]. There's also an outdated check-pvp package [2] but
it requires base < 4.7.

Michal

[1]
http://blog.johantibell.com/2015/03/google-summer-of-code-2015-project-ideas.html
[2] http://hackage.haskell.org/package/check-pvp

On Thu, Apr 9, 2015 at 1:37 PM, Alexey Shmalko <rasen.dubi at gmail.com> wrote:

> As far as I understand PVP, you can't rely on any C. Only which are
> greater-equal to one you tested your package with. It's because minor
> version can introduce changes that are not forward-compatible.
>
> So basically, PVP is Qt versioning scheme with two first numbers being
> Major, third one being Minor and the rest is Patch.
>
> If such convention already exists, what's left is to invent the way to
> enforce it.
>
> On Thu, Apr 9, 2015 at 8:28 PM, Michal Antkiewicz <
> mantkiew at gsd.uwaterloo.ca> wrote:
>
>> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/bbe88185/attachment.html>