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

Benno Fünfstück benno.fuenfstueck at gmail.com
Fri May 16 21:44:38 UTC 2014


I think the problem is that it's impossible to depend on URLs. This means
that the package will not be installable using just `cabal install
<packagename>`, but instead, an user would have to know that he first needs
to install a patched version of `foo` before he can use `<packagename>`.


2014-05-16 18:00 GMT+02:00 Carter Schonwald <carter.schonwald at gmail.com>:

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


More information about the Haskell-Cafe mailing list