duelling pythons
Gil
playing nice with a later install of Python2.2. How do I troubleshoot
this?
TIA
Gerhard Häring
> I think my original install of Python1.5 with RedHat 7.1 is not
> playing nice with a later install of Python2.2. How do I troubleshoot
> this?
What does "python -V" say? 1.5.2 or 2.2?
What does "which python1.5" say? /usr/bin ?
What does "which python2.2" say? also /usr/bin?
If both python1.5 and python2.2 are in /usr/bin and "python -V" says
2.2, you could just "rm /usr/bin/python" and
"ln -s /usr/bin/python1.5 /usr/bin/python" to make 1.5.2 your default
Python. If you want to use Python 2.2 for your scripts later on, just
put:
#!/usr/bin/env python2.2
at the top instead.
Note that there are two flavours of the Python 2.2 RPMs - you'll want
the python2-... one in the future. It installs a "python2" instead of
a "python" symlink in /usr/bin in order to not confuse Redhat's really
clever software.
If the Redhat people cared for Python programmers, they'd simply not
use /usr/bin/python in their scripts but hard-code the required
version.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Geoff Gerrietts
Having done this myself a few times, I can give you some pieces of
advice.
By default, if you're compiling python, you're going to install
/usr/local/bin/python. You can take special measures to do otherwise,
but by default, that's where it ends up.
This puts you in the circumstance of having /usr/local/bin/python and
/usr/bin/python, with /usr/local/lib/python2.2 and /usr/lib/python1.5
supporting these two installs.
You may or may not also have /usr/lib/python2.1 and /usr/bin/python2.
Confirm this. Fire them up, one at a time:
/usr/bin/python
/usr/local/bin/python
Verify that the versions are stated correctly.
Have a look at what else you have installed:
/usr/bin/python*
/usr/local/bin/python*
Most of these are just links to one of the core executables, but some
might be different. My RedHat 7.2 system has Python 1.5, Python 2.1,
and Python 2.2 simultaneously installed. I generally don't use
python2.1, but it does exist (which makes cross-version testing
easier).
Lots of RedHat's software relies on the contents of
/usr/lib/python1.5, which is why it sucks to use RedHat for coding
python these days. (On the other hand, they've got lots of extension
modules for 1.5 pre-installed, which is why it's kinda cool to use
RedHat for coding python these days.)
Because RedHat's software relies on the 1.5.2 binary, there's gonna be
some pain if you want to use 2.2. How you take that pain is up to you.
There are two basic options:
DO REDHAT'S DEPENDENCY MANAGEMENT FOR THEM
The first solution is to just use "python2" whenever you want to
use the new features or write forward-portable code. To accomplish
this:
- Make sure that /usr/bin/python1.5 points to the 1.5.2 binary.
- Make sure that /usr/bin/python points to the version you want to
use.
- Make sure that all RedHat's scripts are fixed to point to
python1.5.
It's the last step that's pretty troublesome. You'll need to go
look at /usr/share. There's a lot in this subdirectory, and a
striking percentage of it uses python. You might try "grep -rl
python ." to extract a list of all the files who look at python.
Not all of these need to be changed, but it's hard to pick out
which do and which don't without knowing how the individual
systems involed operate.
Then check /usr/bin and /usr/sbin the same way -- I think there
are some shell scripts in those directories that invoke python.
This is the way RedHat should have shipped the system, if they
were going to be depending on an old version of the python
interpreter, but they didn't.
SUCK IT UP
The second solution is to make all your scripts and all your
installs of recent tools use python2 instead of python. For
anything that uses distutils, I've found this option works pretty
well -- you call "python2 setup.py" and the package configures
itself and builds itself appropriately.
This can be a little more troublesome with packages or scripts
that assume /usr/bin/python will be the one you want, or scripts
that assume /usr/bin/env python will work properly.
This is a hassle, but it's an ongoing hassle that is unlikely to
consume more than 30 mins of work in a sitting, whereas the
previous task is likely to take many, many hours in up-front time.
There's also one other option, but I'm not sure how feasible it is. It
might be the preferred solution, if you can manage it. It might not be
possible, though.
DO REDHAT'S SYSTEM UPDATING FOR THEM
This path, entirely hypothetical at this point, would involve
downloading and building all the extension modules presently
included in /usr/lib/python1.5 for your new version of the
interpreter.
It may also involve debugging some of the old scripts for the new
environment -- a lot has changed between 1.5.2 and 2.2 that could
have backwards-compatibility ramifications for the scripts. But it
may not.
In some ways, this is the ideal approach, but I don't know how
feasible it is.
It's funny that RedHat is such a big believer in Python that they've
written huge swaths of their distribution-management system in python,
yet at the same time they've made it very challenging for Python
programmers to use their distribution. There's something of an
inconsistency there. :)
Good luck,
--G.
--
Geoff Gerrietts <geoff at gerrietts dot net> http://www.gerrietts.net/
"Politics, as a practice, whatever its professions, has always been the
systematic organization of hatreds." --Henry Adams
nbe...@fred.net
#! /usr/bin/python1.5
If they need a specific version. I argued this with them already.
Keep up the pressure. Maybe they will get it.
Cliff Wells
nbe...@fred.net wrote:
Absolutely agree. Or better #!/usr/bin/python.rh with a link python.rh ->
python1.5 so they can eventually upgrade without changing every shebang.
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Tobias Klausmann
> On 01 Apr 2002 21:56:44 -0500
> nbe...@fred.net wrote:
>
>> Keep lobbying Redhat. The correct solution is for them to put
>>
>> #! /usr/bin/python1.5
>>
>> If they need a specific version. I argued this with them already.
>> Keep up the pressure. Maybe they will get it.
>
> Absolutely agree. Or better #!/usr/bin/python.rh with a link python.rh ->
> python1.5 so they can eventually upgrade without changing every shebang.
In a related matter: how common is /usr/bin/env ?
I really like that tool to run python wherever it is:
#!/usr/bin/env python
As it is part of sh-utils, I guess it's pretty widely used.
Anybody know of specific environments where it is not commonly
available?
so long,
Tobias
Mats Wichmann
:Keep lobbying Redhat. The correct solution is for them to put
:
:#! /usr/bin/python1.5
:
:If they need a specific version. I argued this with them already.
:Keep up the pressure. Maybe they will get it.
The simple fact is that they're not going to make any changes in this
area (even to just fix a batch of scripts) until the next major
version, which unfortunately is still a number of moons away. The
next release was going to be 8.0, but will now be 7.3, if they stories
I've heard are correct, so a reasonble guess might be "no earlier than
the end of the year". Ouch.
Mats Wichmann
Mats Wichmann
<klausman...@tuts.net> wrote:
Windows :-)
It's a standard utility from the UNIX world so it's pretty widespread.
The thing to remember with env is that it uses the current environment
to lookup the thing named python. Which is great if you can precisely
control this in all cases that matter. The environment /is/ going to
be different between your interactive shell and some other program
started in a different context, such as "cron" (which could be asked
to run a Python script for you), or a webserver (as in using Python
for cgi scripts). That's fine as long as you remember to check what
"env" will find in non-shell contexts, and make any necessary
adjustments.
Mats Wichmann
Tobias Klausmann
> On 3 Apr 2002 08:08:18 GMT, Tobias Klausmann
><klausman...@tuts.net> wrote:
>
>:Cliff Wells <logiplex...@earthlink.net> wrote:
>:> On 01 Apr 2002 21:56:44 -0500
>:> nbe...@fred.net wrote:
>:>
>:>> Keep lobbying Redhat. The correct solution is for them to put
>:>>
>:>> #! /usr/bin/python1.5
>:>>
>:>> If they need a specific version. I argued this with them already.
>:>> Keep up the pressure. Maybe they will get it.
>:>
>:> Absolutely agree. Or better #!/usr/bin/python.rh with a link python.rh ->
>:> python1.5 so they can eventually upgrade without changing every shebang.
>:
>:In a related matter: how common is /usr/bin/env ?
>:I really like that tool to run python wherever it is:
>:
>:#!/usr/bin/env python
>:
>:As it is part of sh-utils, I guess it's pretty widely used.
>:
>:Anybody know of specific environments where it is not commonly
>:available?
>
> Windows :-)
Bah, Windows!
No honest, I don't want to spend the money I would have to if
I'd test my software with WinX. I try to stay as portable as
possible, but if it breaks, I have to rely on users' feedback.
> The thing to remember with env is that it uses the current environment
> to lookup the thing named python. Which is great if you can precisely
> control this in all cases that matter. The environment /is/ going to
> be different between your interactive shell and some other program
> started in a different context, such as "cron" (which could be asked
> to run a Python script for you), or a webserver (as in using Python
> for cgi scripts). That's fine as long as you remember to check what
> "env" will find in non-shell contexts, and make any necessary
> adjustments.
So far, I've only written libraries/modules (no shebang) or console
apps that are at least semi-interactive. But if I'd write some such
utility that might run cronned, I'd surely stumble across the system
where cron doesn't know about /usr/local/bin/python15 =)
Greets,
Tobias
Cliff Wells
> In a related matter: how common is /usr/bin/env ?
> I really like that tool to run python wherever it is:
>
> #!/usr/bin/env python
>
> As it is part of sh-utils, I guess it's pretty widely used.
>
> Anybody know of specific environments where it is not commonly
> available?
Well, it exists on Linux and SCO Unix (which implies that it's fairly
common since SCO is next to useless [right below useless, actually]).
However, SCO puts it in /bin, so it unless SCO is unusual in this respect
(wouldn't be a surprise - I'd actually expect it to be found in /etc or
something given their wonderful filesystem layout) it isn't much better
than specifying the path for Python directly.
Michael Hudson
> So far, I've only written libraries/modules (no shebang) or console
> apps that are at least semi-interactive. But if I'd write some such
> utility that might run cronned, I'd surely stumble across the system
> where cron doesn't know about /usr/local/bin/python15 =)
The distutils can help here.
Cheers,
M.
Andy Gimblett
How can distutils help with the problem of what to put on the first
line of my scripts?
--
Andy Gimblett - Programmer - Frontier Internet Services Limited
Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/
Statements made are at all times subject to Frontier's Terms and
Conditions of Business, which are available upon request.
Michael Hudson
> On Wed, Apr 03, 2002 at 09:40:45PM +0000, Michael Hudson wrote:
> > Tobias Klausmann <klausman...@tuts.net> writes:
> >
> > > So far, I've only written libraries/modules (no shebang) or console
> > > apps that are at least semi-interactive. But if I'd write some such
> > > utility that might run cronned, I'd surely stumble across the system
> > > where cron doesn't know about /usr/local/bin/python15 =)
> >
> > The distutils can help here.
>
> How can distutils help with the problem of what to put on the first
> line of my scripts?
Because if you go
python setup.py install_scripts
said scripts get their first lines munged to point to the python used
to install them.
Cheers,
M.
--
58. Fools ignore complexity. Pragmatists suffer it. Some can avoid
it. Geniuses remove it.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Andy Gimblett
> Andy Gimblett <gi...@ftech.net> writes:
>
> > How can distutils help with the problem of what to put on the first
> > line of my scripts?
>
> Because if you go
>
> python setup.py install_scripts
>
> said scripts get their first lines munged to point to the python used
> to install them.
Oooh! NICE!
Thanks for that! :-)
-Andy
Chris Barker
> The simple fact is that they're not going to make any changes in this
> area (even to just fix a batch of scripts) until the next major
> version, which unfortunately is still a number of moons away. The
> next release was going to be 8.0, but will now be 7.3, if they stories
> I've heard are correct, so a reasonble guess might be "no earlier than
> the end of the year". Ouch.
Will they do it for 8.0 anyway??? I'd love to hear them say yes, but I
have heard nothing of the sort.
by the way, in regard to dueling pythons, I have found that If I try to
build a Makefile to buld an extension using: make -f Makefile,pre.in
boot, I get a makefile that is using Python 1.5, when what I want is
Python 2.1. Both are installed, as I want the Redhat tools to work.
How can I get this to work??? It's not obvious to me what I would change
in Makefile,pre.in
-thanks,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception