Python packages installed using pip not on PATH
russell.jones at physics.ox.ac.uk
Thu Jul 16 02:49:22 PDT 2015
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."
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.
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...
More information about the macports-users