On Thu, Apr 23, 2015 at 5:12 PM, Peng Yu wrote:

I had problems with MacPorts for Python and Perl. The general suggestion is to stay way from MacPorts for managing packages offered by other language platforms.

Actually, the general suggestion there is stay away from *any* packaging system for those languages --- because installing modules from both the packaging system and the language's own package repository risks breaking things with incompatible versions. I have had to help someone try to fix their Debian install after they installed a Perl module that was incompatible with dpkg; it's not just MacPorts, or even just Macs. (You can screw up a Red Hat-ish system the same way by installing the wrong Python module(s).) This is why Perl has perlbrew, Python has virtualenv, and Ruby has rvm (and for ghc, both Cabal sandboxes and hsenv). That said, a batteries-included setup like the Platform is usually an exception because you want the compiler and the Platform packages to all match, and you'll break things anyway if they don't: overriding modules that comes with ghc or with the Platform (or Stackage if you use that) is pretty much guaranteed "Cabal hell"). So get those all from the same place, but other modules from wherever --- just don't try to upgrade or replace those packages. You can add a "constraint: <foo> installed" to ~/.cabal/config for each the packages in the global package database to tell cabal-install not to touch those libraries. Note that you will have to exclude the Cabal library itself from that to install a newer cabal-install. This is actually relatively safe, although there is the potential to break ghc-as-a-library in obscure ways. # # # I think MP did end up skipping the latest Platform because the build system changed in a way that's pretty much hostile to other package systems; they've all had to come up with their own ways to build it instead, and our Haskell maintainer did not have the time to work out how to adapt one of them to a ports-based system or design his own alternative. The next Platform release is backing off from that (it ended up being no easier than the old way), so should be easier to update. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net