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

[Nicolas Trangez]

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