I have a mbp, but I've been lazy and have been using ubuntu for my python development thus far b/c its so easy to install modules etc.
How do you install modules on a mac? And best-practises with storing all .py files?
See my lengthy answer to a similar question here. Bottom line, if you are familiar and comfortable with a package-managed environment like on Ubuntu, you may want to use a package manager like MacPorts or Fink or Homebrew on OS X. But there are subtle differences since, unlike Ubuntu, this is not the system-wide package manager so you have to be aware of and co-exist with things supplied by Apple in OS X or by having multiple Python installations.
One of the perks of using high level languages is that they function mostly the same on each platform they support. Python is no diffent. You install modules the same way you do on Linux: using easy_install or pip, check them out http://pypi.python.org/pypi/setuptools http://pypi.python.org/pypi/pip
Related
It is stated in Python documentation here that:
By default, the libraries are searched in prefix/lib/pythonversion and exec_prefix/lib/pythonversion, where prefix and exec_prefix are installation-dependent directories, both defaulting to /usr/local.
But when I looked into my /usr/local directory, what I found was a folder named python2.7. I did install python3.5 not python2.7 on my device (MacBook mid 2012).
You could use sys module to find that.
import sys
print sys.path
Ouput like:
['', '/usr/local/lib/python2.7/dist-packages/mccabe-0.3.1-py2.7.egg', ...
Mac comes with a default Python 2.7 installation. Your installation did not remove python2.7. Probably also the reason why the system libraries are not under usr/local.
You never state how you attempted to install Python 3.5 onto your MacBook, depending on the installation options you used while building the Python source (or the bundle you downloaded) the install location could be different from the defaults. If you provide further details on your installation method, it will be easier to answer all aspects of your question.
As far as I can tell, Apple does not use the installation defaults to provide Python with OSX. On my OSX El Capitan machine, I can see the system Python library at /System/Library/Frameworks/Python.framework/Versions/2.7 and the binary at /usr/bin/python (Python 2.7.x comes preinstalled for all recent versions of OSX).
It looks like the easiest way to get Python 3.5 on Mac is to use MacPython which will install alongside the system version of Python (as you should not alter the default system version of Python or risk breaking OSX). It installs some helper applications into your Finder's Applications directory and installs the library files to /System/Library/Frameworks/Python.framework/Versions/3.5. Since you will have more then one version of Python installed, you would also need to put some effort into making sure your scripts are using the proper version.
If you have a /usr/local/python2.7 directory, that sounds like something that was previously installed by a user. If I remember correctly, OSX does not normally use /usr/local for system software.
Hope that helps
Being fairly new to programming, I am having trouble understanding exactly what Homebrew does... or rather - why it is needed. I know it contains pip for package management, but so does Virtualenv and I'm planning on installing this in due course.
Does Homebrew install another version of python that is not the system version, upon which you would install Virtualenv and manage the different development environments from there?
I have a clean install of OSX Lion and I want to keep my projects separated, but am unsure why I need Homebrew.
I realise this is basic stuff, but if someone could explain it, I would be grateful.
Homebrew is just a package manager for Mac, like pip for Python. Of course you never need a package manager, you can just get all the programs, or libraries in case of pip and Pypi yourself. The point of package managers however is to ease this process and give you a simple interface to install the software, and also to remove it as that is usually not so simply when compiling things yourself etc.
That being said, Homebrew will only install things you tell it to install, so by just having Homebrew you don’t randomly get new versions of something. Homebrew is just a nice way to install general OSX stuff you need/want in general.
pip and virtualenv are python libraries and can be installed in any working python install including the one supplied by Apple as part of OSX and the python.org version.
Then it depends on what you need from python - if you just have to install python libraries or simple C linraries then you can just use easy_install and then pip, vittualenv other python tools.
If you are using more complex C libraries e.g. python interface for mysql then it helps to use a package manager like macports, homebrew or fink as the port writers will have sorted out the tricky dependencies. There are also other python installs from Enthought and Activestate that deal with some of the non simple cases e.g. scipy but are not general purpose package managers.
Macports and fink will install a separate version of python in /opt/local/bin or /sw/bin whilst I think homebrew will use Apple's python. *The difference is due to a difference of view of the package mangers design. Macports and fink were developed by people who experienced a lot of issues with different versions of software and so said that all our installs will be in a place only the package manager uses whilst Homebrew trys to use as much of the Apple supplied tools as possible so to add as little as needed.
There are many versions of Python, and it becomes difficult to manage them all.
Often I need to install one module into 3 different versions of Python.
Is there a tool which can simplify things?
I'm on Windows.
Thanks.
Are you using virtualenv? If not, you definitely want to check that out: http://pypi.python.org/pypi/virtualenv
It helps you by managing and switching between several virtual Python environments, with different versions of Python if you want to.
There are loads of tutorials of how to set it up, all over dem interweb.
What Legogris said: use virtualenv.
I just answered a question on pip, virtualenv, and virtualenvwrapper applicable here. I highly recommend this combination of tools for maintaining isolated python environments.
As a further point, I strong recommend using the no-site-packages option so that each virtualenv has all its requirements in one place.
Because some modules contain binary code which is linked agains a specific Python version, it will not be possible to instal a module only once. You will always have to install it for each installed version. But if you use pip, you should have a look at pip: dealing with multiple Python versions? Just create a batch file which calls pip for each installed version. That should at least simplify your life.
I'm not aware of any Python facility for doing that, that's really the OS's job. Debian/Ubuntu, for example, has support for installing multiple versions of Python and installing libraries into each version. I doubt there's any such support in Windows.
A colleague of mine wants to use my python 2 code on his OS X (10.6) machine. My code imports several built-in python packages, including Tkinter and shelve, and also uses third-party packages, including numpy, scipy, matplotlib, and ipython.
I've encountered a few problems with OS X's built-in python. (IDLE doesn't work, for example*). I suspect I should install a more recent version of python, and a different version of Tk.
My questions:
Will having two different versions of python/Tk on the same machine cause problems?
I would like to associate the terminal commands 'python', 'ipython', and 'easy_install' with the more recent version of python. How should I do this?
When I install third-party packages like numpy using a .dmg file, how do I control which version of python numpy installs into?
Is there a better way to do this?
If this process goes well, I'd consider adding OS X instructions to my code's documentation, so I'd like to boil down this process to the simplest, most general approach.
*EDIT: Also, this
EDIT: Thank you everyone for the useful answers. My colleague tried MacPorts, which seems to work well, but has a few speedbumps. First we had to install Xcode from the system install disk. This is not a fast or lightweight install (several GB). Luckily we still had the disk! Once Xcode was installed, MacPorts was easy to install. Python and the python subpackages we needed were also easy to install, but he told me this installation took several hours. Presumably this delay is due to compilation? He had an easy time setting the MacPorts python as default. However, I think we have to change the 'Python Launcher' application by hand, this seems to still default to the system python.
Even though he has a working system now, I'm tempted to ask him to try one of the other solutions. I'm not sure all of my code's potential users will tolerate a multi-hour, multi-gigabyte installation.
I use brew to install all my libraries/compilers/interpreters.
To install python try this:
brew install python
Then add Python's binaries directory to your $PATH in your ~/.profile:
export PATH=`brew --prefix python`/bin:$PATH
I'd recommend you to install pip, virtualenv and virtualenvwrapper to have better control over your environment too.
Have you tried ActivePython?
It includes a package manager (PyPM) that, by default, installs into your home directory (eg: ~/Library/Python/2.7). Main scripts get symlinked in /usr/local/bin; use the included pythonselect to set the active Python version.
You don't have to bother installing .dmg packages, as PyPM is a binary package manager ... therefore you can install non-pure Python packages like NumPy without having to compile things yourself.
ActivePython can use Apple's Tcl/Tk or, if installed, ActiveTcl.
A "simplest, most general approach" in your documentation could be:
Install ActivePython 2.7
Open Terminal and type pypm-2.7 install matplotlib ipython
Using MacPorts, you can install python 2.6, 2.7, 3.1 and 3.2 at the same time, with their own packages, without ever touching the built-in python.
numpy, scipy, matplotlib, and ipython are also available as ports for most of those python versions.
Moreover, if you install the python_select port, you'll be able:
to choose which one of those (plus the built-in python) is the "default" python;
to install python packages through easy_install/pip for the "selected" python, if they're not available as ports.
Add virtualenv to the mix, and you'll have a very, very flexible Python development environment.
As for your questions:
Q1: with MacPorts, no. while not a frequent user, I've installed and used matplotlib in 2.6 and 2.7, switching between the two using python_select.
Q2: easy_install, pip, ipython will be "linked" to the python they were installed by. (but see tip 1)
Q3: it's easier to install one of the py{26,27,xx}-numpy ports, or pip install numpy under your python_select'ed python.
Q4: well, MacPorts is the best thing I know after APT on Debian/Ubuntu... :-)
Now, two tips if you try MacPorts:
MacPorts cleanly installs ports separately from the OS X installation, in an /opt/local directory, and each python version is installed in a /opt/local/Library/Frameworks/Python.framework/Versions/{2.5,2.6,2.7,...} directory. Using python_select cleanly switch the "python" command using links. BUT... the Versions/{2.5,2.6,2.7,...}/bin directory, where python scripts are installed, is not added to the PATH. Just adding: export PATH=/opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:$PATH to your ~/.profile will always give you direct access to the scripts installed for the selected python.
to avoid bad surprises, I've added a echo Selected python is \"$(python_select -s)\" line to my ~/.profile, so I always know which is my currently selected python when opening a session... :-)
Regards,
Georges
In almost all cases, the best python to use is the one from http://python.org/. It sets up the paths correctly and doesn't overwrite anything. DMG package installs usually work automatically, as does python setup.py install, and it's not too hard to get setuptools to work. If you want per-user installs, it is easy to set up .pydistutils.cfg and python automatically recognizes the path install_lib = ~/Library/Python/$py_version_short/site-packages
An addendum regarding the usage of brew:
Since some time, brew install python will install python3.
If you intend to install python2, you want to use
brew install python#2
It is perfectly fine to install both python and python3 using brew!
Here is an old post that answers your questions too.
In general it is not a problem at all to have more than one python installation on your machine. You just have to watch out which one you are calling on the command line.
>> which python
... helps to identify where your python binary is located. The original Mac OS X python is usually at "/usr/bin/python"
I personally use the MacPorts python installation. It also supports you with the installation of modules. (see link above)
I have 4 versions of python on my MacBook Pro. 2 from the original install of OS X 10.6 and a subsequent update, then self installed copies of python 2.7 and 3.2. You can update the python command to point at any of the versions. They all install in separate directories and cause no problems with each other.
I'm not sure what will happen when you install from a .dmg file. I believe it will simply use whatever version python points to.
This post on superuser.com answers your questions on changing default paths.
Background
I don't develop using OS X's system provided Python versions (on OS X 10.6 that's Python 2.5.4 and 2.6.1).
I don't install anything in the site-packages directory for the OS provided versions of Python. (The only exception is Mercurial installed from a binary package, which installs two packages in the Python 2.6.1 site-packages directory.)
I installed three versions of Python, all using the Mac OS X installer disk image:
Python 2.6.6
Python 2.7
Python 3.1.2
I don't like polluting the site-packages directory for my Python installations. So I only install the following five base packages in the site-packages directory. For the actual method/commands used to install these, see SO Question 4324558.
setuptools/ez_setup
distribute
pip
virtualenv
virtualenvwrapper
All other packages are installed in virtualenvs.
I am the only user of this MacBook.
Questions
Given the above background, why should I install the five base packages in ~/.local? Since I'm installing these base packages into the site-packages directories of Python distributions that I've installed, I'm isolated from the OS X's Python distributions.
Using this method, should I be concerned about Glyph's comment that other things could potentially break (see his comment below)?
Again, I'm only interested in where to install those five base packages.
Related Questions/Info
I'm asking because of Glyph's comment to my answer to SO question 4314376, which stated:
NO. NEVER EVER do sudo python setup.py install whatever. Write a ~/.pydistutils.cfg that puts your pip installation into ~/.local or something. Especially files named ez_setup.py tend to suck down newer versions of things like setuptools and easy_install, which can potentially break other things on your operating system.
Previously, I asked What's the proper way to install pip, virtualenv, and distribute for Python?. However, no one answered the "why" of using ~/.local.
There's no particularly good reason for or against installing in .local for Mac OS X installations using framework builds. There is still some controversy among Python core developers on this point with Glyph arguing that the .local location, introduced in Python 2.6 for other Unixy systems, should be used for Mac OS X and simplifies third-party installation processes, while others argue that the previous traditional locations for Mac OS X framework builds is more natural. In the end, it is up to you. Particularly if you are using virtual environments, if it works, don't worry about it.
As of 2020, I do not think it is a good idea to install Python packages into .local, but to use virtualenv to create a separate environment for each package.
My reason
While installations into .local do not interfere with the system wide Python, you still can have conflicts between several packages installed into .local.
P.S.: If you do you like virtualenv you could also use pipx.