Cabal Dependency Hell

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Cabal Dependency Hell

Jonathon Delgado
According to a few articles I've read, cabal dependency hell is caused by
installing packages with -o, which inlines code from dependant packages.

Why isn't this avoided by installing packages without inlining? Packages
could still be recompiled with -o in a cabal-dev sandbox, but the package
repository would be free of dependency hell.



Reply | Threaded
Open this post in threaded view
|

Cabal Dependency Hell

Brandon Allbery
On Mon, May 27, 2013 at 3:33 PM, harry <voldermort at hotmail.com> wrote:

> According to a few articles I've read, cabal dependency hell is caused by
> installing packages with -o, which inlines code from dependant packages.
>

-O, not -o.


> Why isn't this avoided by installing packages without inlining? Packages
>

Because the performance is somewhere between horrible and abysmal.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130527/df81f8c3/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Cabal Dependency Hell

Jonathon Delgado
Brandon Allbery <allbery.b <at> gmail.com> writes:

> Why isn't this avoided by installing packages without inlining? Packages ...
>
> Because the performance is somewhere between horrible and abysmal.

Thank you, does this mean that dynamic linking wouldn't work either?



Reply | Threaded
Open this post in threaded view
|

Cabal Dependency Hell

Brandon Allbery
On Tue, May 28, 2013 at 3:37 AM, harry <voldermort at hotmail.com> wrote:

> Brandon Allbery <allbery.b <at> gmail.com> writes:
> > Why isn't this avoided by installing packages without inlining? Packages
> ...
> >
> > Because the performance is somewhere between horrible and abysmal.
>
> Thank you, does this mean that dynamic linking wouldn't work either?


Dynamic linking is an even bigger ball of snakes, yes. :/ A better solution
would be nice, but I'm not aware of any magic that can be applied to it.
(The GHC devs know a better solution is needed; unfortunately, the best
they've come up with is a proposal to build everything against everything
else in every possible combination....) Not that there are any better ideas
sitting around. Maybe whole program compilation, which would require all
libraries to be available in source form (and would make dynamic linking
meaningless since every compiled library would be a one-off).

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130528/d3baf0f0/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Cabal Dependency Hell

Peter Hall
> The GHC devs know a better solution is needed; unfortunately, the best
they've come up with is a proposal to build everything against
> everything else in every possible combination....

Surely that isn't necessary; it could be done lazily. That is, compile
every combination that is actually demanded by their respective cabal
files. No?

Peter



On 28 May 2013 15:58, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Tue, May 28, 2013 at 3:37 AM, harry <voldermort at hotmail.com> wrote:
>
>> Brandon Allbery <allbery.b <at> gmail.com> writes:
>> > Why isn't this avoided by installing packages without inlining?
>> Packages ...
>> >
>> > Because the performance is somewhere between horrible and abysmal.
>>
>> Thank you, does this mean that dynamic linking wouldn't work either?
>
>
> Dynamic linking is an even bigger ball of snakes, yes. :/ A better
> solution would be nice, but I'm not aware of any magic that can be applied
> to it. (The GHC devs know a better solution is needed; unfortunately, the
> best they've come up with is a proposal to build everything against
> everything else in every possible combination....) Not that there are any
> better ideas sitting around. Maybe whole program compilation, which would
> require all libraries to be available in source form (and would make
> dynamic linking meaningless since every compiled library would be a
> one-off).
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130530/707fee6c/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

Cabal Dependency Hell

Brandon Allbery
On Wed, May 29, 2013 at 7:32 PM, Peter Hall <peter.hall at memorphic.com>wrote:

> > The GHC devs know a better solution is needed; unfortunately, the best
> they've come up with is a proposal to build everything against
> > everything else in every possible combination....
>
> Surely that isn't necessary; it could be done lazily. That is, compile
> every combination that is actually demanded by their respective cabal
> files. No?
>

That is probably how it would be done, but it still means potentially a
combinatorial explosion of libraries, plus a lot of extra building
sometimes that you might not expect because "isn't that already built?!".

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130529/2450da30/attachment.htm>