Python packages installed using pip not on PATH

[Russell Jones]

One can similarly break OS X by installing to the system Python
"The Apple-provided build of Python is installed in 
/System/Library/Frameworks/Python.framework and /usr/bin/python, 
respectively. You should never modify or delete these, as they are 
Apple-controlled and are used by Apple- or third-party software. 
Remember that if you choose to install a newer Python version from 
python.org, you will have two different but functional Python 
installations on your computer, so it will be important that your paths 
and usages are consistent with what you want to do." 
https://docs.python.org/2/using/mac.html

Having a secondary full Python install using Anaconda is the closest 
equivalent to MacPorts on Linux, though there are pros and cons relative 
to virtualenvs + -dev packages. Once the metadata issues on Linux are 
sorted, allowing pre-built binary wheels (already available on Windows 
and OS X) I'd say virtualenvs will have the edge.

The main thing I've run into with virtualenvs on both platforms is 
having the relevant development libraries available, and MacPorts deals 
with this well in a lot of cases.

Russell

On 16/07/15 01:50, Brandon Allbery wrote:
>
> All of Perl, Python, and Ruby recommend you do not install manually 
> any modules / packages in a package manager-provided tree, not even 
> with standard utilities like Perl's cpan. There are very good reasons 
> for this, although less applicable to MacPorts than to, say, Linux 
> (where installing the wrong Perl module on a Debian-ish system can 
> break dpkg/apt-get, or the wrong Python module on a Red Hat-ish system 
> can break yum. I've actually had to help someone try to recover from 
> the former).
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20150716/459db4cf/attachment.html>