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

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 wrote:

...

2014-05-15 9:30 GMT+02:00 Roman Cheplyaka :

...

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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe