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

[Markus Läll]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140516/0649953e/attachment.html>