how to build with 2.4 having 2.6 as main python

[Alexzive]

Hello there,

my Mandriva has the 2.6.4 python pre-installed (in /usr/lib64/
python2.6/)
I need to install numpy 1.4 for python 2.4.3 (I installed it
separately from source on/usr/local/lib/python2.4/ )

but still typing "python" I get:
Python 2.6.4 (r264:75706, Jan 8 2010, 18:59:59)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
what to change in order to get "python" calling python 2.4.3 instead
of 2.6.4 (at least during python setup.py build)?

I suppose I need something like changing the link to /usr/local/bin/
python..
but I fear to do something bad by myself..
please help!

 

[James Mills]

what to change in order to get "python" calling python 2.4.3 instead
of 2.6.4 (at least during python setup.py build)?

I suppose I need something like changing the link to /usr/local/bin/
python..
but I fear to do something bad by myself..
please help!

Just run the python-2.4 binary.

There will likely be a /usr/bin/python-2.4 or similar.

cheers
James

 

[Steven D'Aprano]

what to change in order to get "python" calling python 2.4.3 instead of
2.6.4 (at least during python setup.py build)?

That will do bad things to your system, which will be expecting the
system Python to be 2.6 and instead will be 2.4. You will probably find
system tools will start to fail.

I suppose I need something like changing the link to /usr/local/bin/
python..
but I fear to do something bad by myself.. please help!

Yes, that will do it, but if you do, you will probably break things. Best
to just call the python2.4 binary directly.

If you call

python2.4

from the command line, what happens?

 

[Alexzive]

thanks guys,

the solution for me was

python2.4 setup.py install --prefix=/usr/local

cheers, AZ

 

[Benjamin Kaplan]

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.

 

[Hans Mulder]

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

 

[Benjamin Kaplan]

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