I believe part of the problem for Ron there is a.) speed of the community & lack of communication, b.) lack of consistent tool isolation. You notice he's using RVM (while most of the Ruby developers I know have moved to rbenv due to better support) and that it was out of date. Also, he had the foresight to isolate his Ruby tooling by using rvm (good on 'ya, Ron!) for bizarre system dependencies, but did not chose to use a similar Python environment manager strategy such as pyenv of pythonbrew (for suffering the same damn problems). I sincerely empathize with him, but some of this can be argued as the cost of doing development n! generations past we recognized the impact of 'internet time'.
These issues also crop up with installing python libraries via pip in a system managed by apt/yum/whatever, from what I remember. Dealing with Python versions / libraries that are not part of the OS's package manager can be painful. It's why people use things like virtualenv / pyenv / Docker even in controlled server environments.
Yup. Really, no OS is developer-friendly if you're going to mess with the system Python interpreter, because the system Python interpreter exists to serve system software written in Python. You can easily get yourself into very similar problems with Debian or Fedora or whatever else.
Install a virtualenv, and on OS X, maybe install Python from python.org, and then everything works amazingly.
After I learned more that was probably the right thing to do, but I'm not a python dev. I just want to use sklearn, pandas, and associated tools. I'm not sure what the smooth path to doing that is. At various times people recommend macports, brew, anaconda, and so on... Note that compiling numpy from source sucks, and I'd much rather someone else do so.
There are now wheels (binary distributions of Python modules) of numpy, scipy, and scikit-learn for both Linux and Mac OS X, so it should just be a matter of `virtualenv /tmp/v` (or wherever), `source /tmp/v/bin/activate`, `pip install -U pip` to make sure your pip is new enough to handle wheels, and `pip install numpy scipy scikit-learn`. Nothing gets built from source. Unfortunately the same can't (yet) be said for pandas; `pip install pandas` at this point will try to compile it.
Actually acquiring virtualenv on OS X seems not to be super straightforward, especially if you want to use the system Python interpreter. The best option seems to be to `brew install python`, and then `pip install virtualenv`. Or download Python from python.org, and maybe get Python 3 while you're at it.
one way is to get a standalone python and git clone virtualenv, then use the standalone python to make virtualenv for each project.. this leaves out anything to do with the system python
TBH, it really is not dev friendly due to odd/old versions, having to install brew etc.
Thus, I use my Mac as a fronted with business apps but all dev is done on Linux VMs. I like the separation and avoid all that hair pulling.
Now, dealing with proprietary HW is a whole other can of worms. I spent 3hrs last night trying to load a LE cert into a Polycom phone but had ZERO success getting the phone to use it instead of the factory cert. ARGH.
Which components are hackable? The closed-source kernel? The closed-source userspace libraries? The Internet service infrastructure (iCloud &c.)? The outdated versions of open-source software?
You have root, and you can build your own enclave of open-source code doing as you desire, but this is true of pretty much any system--certainly it's true on Windows, at least.