Thanks! pete On Tue, Feb 04, 2014 at 11:48:52PM -0500, Brandon Allbery wrote:

On Tue, Feb 4, 2014 at 10:29 PM, wrote:

...

I'm having trouble wrapping my head around how to work with Hackage in the context of a Linux distribution that already has its own package management situation. Between distribution-provided packages containing Haskell programs and/or libraries, system-wide cabal installs, user-specific cabal installs, and cabal sandboxes, I can't seem to work out how the hackage/cabal architects intend people (ie, me) to juggle things.

This is not a Hackage-specific issue; you will run into it with any language ecosystem, and every language ecosystem has its own mechanisms for dealing with it (usually involving some form of sandboxing). Indeed, some languages pretty much require those mechanisms: all too often, you need a separate rvm sandbox for multiple Ruby applications....

The general rule is that if you're just looking to install a few things available from OS packages and are not doing development, use the OS packages; otherwise, install just enough to be able to use cabal to install stuff. Although this also may vary: in many cases you will want to install the Platform libraries from your OS because you should really only have one version installed and it should generally be the "blessed" stable version. But if you're [say] intending to work with bleeding edge Yesod, then you probably want to only install ghc and cabal-install from the OS.

Anyway, this question is why Haskell has hsenv, cabal-dev, and cabal sandboxes; Ruby has rvm, Python has virtualenv, and Perl has perlbrew, and other languages have their own mechanisms to deal with the same problems. And pkg-config is (de facto and for the moment) the solution C and C++ use, attacking it from a different direction.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

The most robust approach is to find or create distro packages for everything you need.

How does this handle the situation where I want both package A and package B installed, but they each want a different version of package C?

...

How does this handle the situation where I want both package A and package B installed, but they each want a different version of package C?

How would your distro handle it if those packages were written in C?

I'd say the C-leaning factions of the open-source community have largely accepted the convention that ABI/API changes that cause incompatibilities are accompanied by bumps in the major version number. There are, of course, exceptions, but my feeling is they are rare, generally well-publicized, and quickly fixed. To be honest, I don't even know if hackage authors tend to follow this convention because...

With Haskell it seems worse because everything has conservative dependencies in a *.cabal file and Cabal will refuse to build the thing unless they're met.

... Haskell seems worse to me in that if package foo is updated, every other package depending on foo (recursely) must then be rebuilt, even if they didn't change and even if the interface presented by foo didn't change. C programs do not suffer similarly and my limited experience with ``cabal hell'' would have been a non-event if this recompilation process wasn't necessary. I don't know what technical issues necessitate it and I don't know whether the conventions required to make it feasible are already in place, which is partially what I'm trying to learn here. =) Additionally, it seems that the hackage ecosystem is far more intertwined than that of third-party Python packages (I have no experience with Ruby). That is, many things in hackage depend on other things in hackage whereas far more Python packages depend only on the libraries included in the base install. This is not a knock against Haskell by any means; it is, in fact, a testament to the powerful abstractions it supplies and enables. It does, however, weaken the ``other languages have this problem, too'' argument. Perhaps the solution is a more rigorous effort to keep the Haskell Platform up to date, especially with well-regarded ``building block'' libraries (eg, lens), and possibly even on a fixed schedule. Then hackage authors can be encouraged to make their stuff compatible with particular releases of the Haskell Platform and ``normal'' users would only need to worry about upgrades whenever the Platform is updated. But then we're really edging out on the slippery slope to Haskell becoming a distro unto itself. pete

Brandon Allbery wrote:

I do find myself wondering if anyone has checked to see how important the inlining is these days; perhaps ghc's general performance (and a hat tip to Moore's law) has made it possible to consider compiling more stable libraries.

Lately, I have been looking at GHC Core output for unrelated reasons, and it appears to me that cross-module inlining is essential to GHC performance. For instance, if you don't inline the monadic combinators (>>=) and `return` for the IO monad and perform even more inlining afterwards, performance can easily differ by an order of magnitude. The reason is that the second argument of (>>=) is a closure. Closure creation is very expensive compared to the sequence of primops you get after inlining. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com