[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:10:13 UTC 2014

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.

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
>