how to build with 2.4 having 2.6 as main python
in [Python]
|
Prev: what are some good python modules?
Next: Good solutions for passing around large numbers of argumentsin a layered architecture?
From: Hans Mulder on 14 Jun 2010 16:36 Benjamin Kaplan wrote: > On Mon, Jun 14, 2010 at 3:09 AM, Alexzive <zasaconsulting(a)gmail.com> wrote: >> thanks guys, >> >> the solution for me was >> >> python2.4 setup.py install --prefix=/usr/local >> >> cheers, AZ >> > > Don't do that! Like Steven said, you'll kill your system that way. > Lots of programs in Linux use Python and those programs expect > /usr/bin/env python to map to python2.6. Other versions of Python > should be referenced by the version: so python2.4 for Python 2.4, > python3 or python3.1 if you decide to install Python 3.1. Which Linux distribution are you using? My Debian system does what I consider to be the Right Thing: python scripts provided by Debian bin with "#!/usr/bin/python". This allows me to install some version of Python in another directory and have that one first in my $PATH, so that if I type python, I get the one I want and if a system utility needs the system Python, they'll get their version and nothing breaks. I happen to be a fan of virtualenv; virtualenv depends on this feature. Cheers, -- HansM
From: Benjamin Kaplan on 15 Jun 2010 19:26
On Tue, Jun 15, 2010 at 3:55 PM, Dan Stromberg <drsalists(a)gmail.com> wrote: > > I don't think #!/usr/bin/env python is the right thing - unless a script > really doesn't care much what version of python it gets. > > I used to #!/usr/bin/env everything, but I've been updating my old scripts > not to. It's just too much trouble, despite the one minor simplification it > provides. > > My Ubuntu 10.04 system has a mix of the two, but there are more > #!/usr/bin/python's. That concerns me a bit, because I've needed to install > a half dozen versions of python in the past, and soon will do so on this > machine. Of course, I rarely change my $PATH to include one of these > alternative python's (which is probably the salient issue), but I don't want > to be stuck being unable to do so if the need does arise. > > I spent a year working in PowerShell, to my surprise. What a pain it was > not being able to install more than one version at the same time. May > Python never have that problem! > #!/usr/bin/python doesn't mean you care about what version of Python you use, it means you care about what *location* you use. If I'm on Ubuntu 8.04, it's Python 2.5. If I'm on Ubuntu 10.04, it's Python 2.6. And what happens if you bring your script to a distribution that puts its python installs in /usr/local/bin? If you care what version of Python you get, then do #!/usr/bin/env python2.6 which will run it under a specific version of Python. All Python installs include the pythonX.X executable, and then one of those executables is symlinked to python. Common convention on Linux and Mac OS X (probably other Unix-based systems as well) is to leave /usr/bin/env python pointing to the system's default Python install (wherever it is) and to altinstall the other versions of Python (so you access them by specifying the version number). This is what Ubuntu does if you install multiple versions through the package manager. Lucid has 2.6 (system default) and 3.1. Karmic has 2.4, 2.5, 2.6 (system), and 3.1. /usr/bin/python and /usr/bin/env python always point to the system version, the other versions are specified through /usr/bin/pythonX.X |