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

16 May 2014

      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 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 
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
-- 
Markus Läll