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

Carter Schonwald carter.schonwald at gmail.com
Fri May 16 16:00:46 UTC 2014


You can totally cabal install from a URL.

A good example of this Johan shared a URL pointing to a Tarball when he
wanted testers befor he released an update to cabal and cabal install.

It's really easy.  Cabal sdist the project as per usual, but instead put it
somewhere online where it has a URL.  Then cabal install URL.  This
actually works.

On Friday, May 16, 2014, Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com>
wrote:

> On 16 May 2014 21:10, Tomas Carnecky <tomas.carnecky at gmail.com<javascript:;>>
> wrote:
> > 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.
>
> How does that solve anything?  You still end up potentially needing
> multiple different forks of a package!
>
> >
> > 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--
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com <javascript:;>
> http://IvanMiljenovic.wordpress.com
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140516/62c18dff/attachment.html>


More information about the Haskell-Cafe mailing list