[Haskell-cafe] Eager forking on Hackage and inter-library compatibility (was: Re: possible bug in latest hackage Elf (Elf-0.27))

Fri May 16 11:29:45 UTC 2014

On 16 May 2014 21:10, Tomas Carnecky <tomas.carnecky at gmail.com> wrote:
> Teach cabal how to install packages from a URL or even a git
> repository, like go or npm can. Then people can upload the patched
> project to (or even fork on) github/bitbucket/.. and let others know
> so they can update their cabal file.

How does that solve anything?  You still end up potentially needing
multiple different forks of a package!

>
> On Fri, May 16, 2014 at 12:26 PM, Markus Läll <markus.l2ll at gmail.com> wrote:
>> I now see what you mean and you are totally right.
>>
>> I guess what people are craving for, is a seamless solution to fix the
>> problem quick, and have it be public right away to yourself and others who
>> need it. Maybe this is material for a later discussion, but as just a
>> thought, maybe the eager ones could manage an eager hackage to host their
>> changes (a private hackage has been mentioned before). More work upfront,
>> but might be worth it in the end.
>>
>>
>>
>>
>> On Fri, May 16, 2014 at 11:27 AM, Nicolas Trangez <nicolas at incubaid.com>
>> wrote:
>>>
>>> On Fri, 2014-05-16 at 11:04 +0200, Markus Läll wrote:
>>> > I would argue *for* forking. Hackage is big and consists of many
>>> > packages
>>> > which have only a few users, or maybe just one -- the author. I don't
>>> > see
>>> > all these packages if I don't go on the page and look. But when I do, I
>>> > will be looking for *them*. If some popular package stops working then I
>>> > would be happy to find a fork, because now I can just tell cabal about
>>> > it.
>>> > And if the original gets fixed, I can go back. I don't think people who
>>> > fork are looking for aquiring yet another package to maintain forever,
>>> > or
>>> > to take it over.
>>>
>>> tl;dr: Eagerly forking is all nice and shiny for 'leaf' packages which
>>> don't expose common functionality, but causes troubles for packages
>>> which are common library dependencies.
>>>
>>> Doesn't this cause issues with library interoperability?
>>>
>>> Say there's a package which implements some standard datatype, e.g.
>>> 'vector' by author V. Then there are 2 other packages,
>>> 'vector-algorithms' by author A and 'complex-vector-algorithms' by
>>> author C.
>>>
>>> 'vector' exports a datatype 'Vector'.
>>> 'vector-algorithms' exports a function 'a :: Int -> Vector'.
>>> 'complex-vector-algorithms' exports a function 'c :: Vector -> Float'.
>>>
>>> Finally, there's the application author who wrote the function
>>> 'ingeniousCalculation :: Int -> Float; ingeniousCalculation = c . a'
>>>
>>> Now, the author of C finds an obscure bug in some function in 'vector'
>>> he uses (caused by a bug in some internal 'vector' function which
>>> requires access to non-exported internals of the Vector type), and sends
>>> a patch to V. This bug doesn't impact 'vector-algorithms' in any way.
>>>
>>> V doesn't reply within 48 hours, so C impatiently uploads 'vector-c' to
>>> Hackage, containing the fix, and updates the 'complex-vector'algorithms'
>>> dependencies from 'vector' to 'vector-c' (with whatever version
>>> constraint).
>>>
>>> At this point, the code by the application author breaks since
>>> 'vector-algorithms' uses 'Vector' from the 'vector' package, and
>>> 'complex-vector-algorithms' uses 'Vector' from 'vector-c', which are
>>> different types from a compiler perspective.
>>>
>>> I see 3 solutions:
>>> - 'vector-algorithms' needs to be updated by A to use 'vector-c',
>>> something to which A might be reluctant since it could break lots of
>>> code using 'vector-algorithms' in combination with other libraries and
>>> applications using 'vector'.
>>> - The application author needs to patch 'vector-algorithms' locally to
>>> use 'vector-c'.
>>> - The application author patches 'vector' locally to fix the bug
>>> (something V wil most likely do in a couple of days) and reverts the
>>> dependency of 'complex-vector-algorithms' from 'vector-c' back to
>>> 'vector'.
>>>
>>> None of these seem very satisfactory.
>>>
>>> So, whilst forking (in this case) provides a very 'local' solution for
>>> the 'complex-vector-algorithms' package and C, it doesn't fix anything
>>> (I'd even argue it complicates matters) in the grand scheme of things.
>>>
>>> My .02,
>>>
>>> Nicolas
>>>
>>> >
>>> >
>>> >
>>> > On Thu, May 15, 2014 at 11:18 AM, Sven Panne <svenpanne at gmail.com>
>>> > wrote:
>>> >
>>> > > 2014-05-15 9:30 GMT+02:00 Roman Cheplyaka <roma at ro-che.info>:
>>> > > > If there's no response, then you have two choices:
>>> > >
>>> > > Actually three: Fix things locally until the "official" package is
>>> > > fixed.
>>> > >
>>> > > > * request package maintainership, which will take several weeks
>>> > >
>>> > > I really hope that this will take months, not weeks, see the other
>>> > > discussion
>>> > >
>>> > > > * fork the package (i.e. upload your patched version to hackage
>>> > > > under a
>>> > > >   different name)
>>> > >
>>> > > This proposal worries me quite a bit, because if everybody follows
>>> > > that advice, it will turn Hackage into a chaotic collection of
>>> > > packages with various degrees of being fixed/maintained/etc. Imagine a
>>> > > package 'foo', which needs a fix, and several pepole think it's a good
>>> > > idea to fork and fix the issue at hand. Now we have 'foo', 'foo-XY',
>>> > > 'foo-my-cool-acronym', ... Of course people normally have no incentive
>>> > > to really take over maintainership for 'foo', they just want a working
>>> > > 'foo' right now for their own project. Later the real maintainer
>>> > > re-appears after vacation/sabbatical/whatever, fixes 'foo', and
>>> > > continues to work on it, adding new features. Now somebody new comes
>>> > > to Hackage to see if there is already a package for some use case, and
>>> > > finds 'foo', 'foo-XY', 'foo-my-cool-acronym', ... Then it takes some
>>> > > non-trivial detective work to find out which packages are actually
>>> > > dead (again) and which is the real one. => Chaos IMHO.
>>> > >
>>> > > In a nutshell: If you are really in a hurry, fix things locally.
>>> > > Hackage is not the place to fork like hell.
>>> > > _______________________________________________
>>> > > Haskell-Cafe mailing list
>>> > > Haskell-Cafe at haskell.org
>>> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> > >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>>
>>
>> --
>> Markus Läll
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com