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@gmail.com> wrote:

On 16 May 2014 21:10, Tomas Carnecky <tomas.carnecky@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@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@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@gmail.com
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe