views:

725

answers:

3

If you install multiple versions of python (I currently have the default 2.5, installed 3.0.1 and now installed 2.6.2), it automatically puts stuff in /usr/local, and it also adjusts the path to include the /Library/Frameworks/Python/Versions/theVersion/bin, but whats the point of that when /usr/local is already on the PATH, and all installed versions (except the default 2.5, which is in /usr/bin) are in there? I removed the python framework paths from my PATH in .bash_profile, and I can still type "python -V" => "Python 2.5.1", "python2.6 -V" => "Python 2.6.2","python3 -V" => "Python 3.0.1". Just wondering why it puts it in /usr/local, and also changes the PATH. And is what I did fine? Thanks.

Also, the 2.6 installation made it the 'current' one, having .../Python.framework/Versions/Current point to 2.6., So plain 'python' things in /usr/local/bin point to 2.6, but it doesn't matter because usr/bin comes first and things with the same name in there point to 2.5 stuff.. Anyway, 2.5 comes with leopard, I installed 3.0.1 just to have the latest version (that has a dmg file), and now I installed 2.6.2 for use with pygame.

EDIT: OK, here's how I understand it. When you install, say, Python 2.6.2: A bunch of symlinks are added to /usr/local/bin, so when there's a #! /usr/local/bin/python shebang in a python script, it will run, and in /Applications/Python 2.6, the Python Launcher is made default application to run .py files, which uses /usr/local/bin/pythonw, and /Library/Frameworks/Python.framework/Versions/2.6/bin is created and added to the front of the path, so 'which python' will get the python in there, and also #! /usr/bin/env python shebang's will run correctly.

+5  A: 

There's no a priori guarantee that /usr/local/bin will stay on the PATH (especially it will not necessarily stay "in front of" /usr/bin!-), so it's perfectly reasonable for an installer to ensure the specifically needed /Library/.../bin directory does get on the PATH. Plus, it may be the case that the /Library/.../bin has supplementary stuff that doesn't get symlinked into /usr/local/bin, although I believe that's not currently the case with recent Mac standard distributions of Python.

If you know that the way you'll arrange your path, and the exact set of executables you'll be using, are entirely satisfied from /usr/local/bin, then it's quite OK for you to remove the /Library/etc directories from your own path, of course.

Alex Martelli
What if I removed, say, Python 2.6? I could remove it from /Applications and /Library/..../Versions/2.6.2, but what about the /usr/local/? Wouldn't a bunch of broken symlinks get left behind? And I wouldn't want to mess around in there trying to pick out the 2.6.2 ones.. I don't know..
Mk12
Yep, you'd have to specifically remove the (few) 2.6-specific symlinks, unless you're using a distro that comes with an "uninstall" (I believe the standard one from python.org doesn't) -- `ls -l /usr/local/bin | grep 'Python.*2.6'` will easily identify them, of course, so there's no "mess around" nor "trying to pick".
Alex Martelli
Couldn't I also get rid of everything in /usr/local/bin and just put the /Python.framework/Versions/x.x.x/bin on the path in whatever order I want?
Mk12
@Mk12, yep, that would be a perfectly OK alternative -- unless there are other thinks installed in your /usr/local/bin that have nothing to do with different Python versions, of course.
Alex Martelli
A: 

I just noticed/encountered this issue on my Mac. I have Python 2.5.4, 2.6.2, and 3.1.1 on my machine, and was looking for a way to easily change between them at will. That is when I noticed all the symlinks for the executables, which I found in both '/usr/bin' and '/usr/local/bin'. I ripped all the non-version specific symlinks out, leaving python2.5, python2.6, etc, and wrote a bash shell script that I can run as root to change one symlink I use to direct the path to the version of my choice

'/Library/Frameworks/Python.framework/Versions/Current'

The only bad thing about ripping the symlinks out, is if some other application needed them for some reason. My opinion as to why these symlinks are created is similar to Alex's assessment, the installer is trying to cover all of the bases. All of my versions have been installed by an installer, though I've been trying to compile my own to enable full 64-bit support, and when compiling and installing your own you can choose to not have the symlinks created or the PATH modified during installation.

lewisblackfan
+1  A: 

what about python's virtualenv package? that seems to be a fairly popular way of having multiple python installations on one machine. have other users done this on their os x machines?

Rayjan