Stack Compatibility with OS X Package Managers

Data Management
#1

There’s been some talk on HipChat regarding various vague incompatibilities between the stack and various Mac OS package managers. It seems like we should gather some of those experiences and try to determine exactly what we are compatible or incompatible with, and possibly figure out why.

I don’t have any direct experience with any of the Mac package managers, but at one point I think I came to the conclusion that Homebrew was the only one for which real compatibility with EUPS was possible, since (I think) it puts the files it installs into per-package prefix directories, though I think it also puts symlinks to all of them into a single prefix directory. It’s the latter kind of thing that causes problems (because you put the everything-prefix into your various paths to get one package, and then something else in that directory overrides something EUPS provides).

Discourse is rude to new users, not enough posting powers
#2

FWIW, fink, has in general worked fine for me.

#3

I use Macports. It works pretty well. The only issue I’m aware of is that installing GCC with Macports creates an /opt/local/bin/c++ symlink to g++. This may well appear ahead of /usr/bin/c++ on your path and get invoked instead. This will break since you can’t use GCC to build the stack on a Mac (see DM-3405). This is Macports #48647.

I’m not sure I fully understand the significance of Jim’s comments about EUPS compatibility. I can imagine a situation in which EUPS could do neat tricks based on the per-package directories Homebrew uses. However, as far as I know, the same sort of “incompatibility” would occur between EUPS and the standard Linux deb/RPM package managers (which tend to dump things into /usr) – given that, I’m not sure if we’d actually want to take advantage of Homebrew’s special features. Am I missing the point?

#4

I use homebrew and I think it’s great, but, if I was going to use homebrew python for my stack I’d first setup a virtual environment rather than installing into the homebrew tree. This is mainly because I historically have an aversion to ever installing perl/python packages into system managed trees.

#5

So, I’ve tried this (with homebrew + virtualenv / virtualenvwrapper) and it didn’t work with an eups distrib source installation. Has anyone got this to work? Certainly we should work towards this because it’s currently the de facto standard workflow for Python development on a Mac (if you’re not in the Anaconda ecosystem).

#6

is that the same error as reported in DM-3754?

#7

I confirmed that the fix @mjuric mentioned worked for me to address the Homebrew --prefix vs. --home conflict.

It has been submitted as a Pull Request.

#8

A post was split to a new topic: Discourse is rude to new users, not enough posting powers

#9

The fix looks good, waiting for @RHL to approve the merge. I’m not sure if there’s time to uprev EUPS for this release, though – but if it’s too risky, EUPS can be upgraded later as well (it’s not packaged with the release as other things are).