FAQ
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?

TIA

Search Discussions

  • Gerhard Häring at Apr 1, 2002 at 5:42 am

    Gil wrote in comp.lang.python:
    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 at Apr 1, 2002 at 8:56 pm

    Quoting Gil (gjlap at yahoo.com):
    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?
    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
  • Nbecker at Apr 2, 2002 at 2:56 am
    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.
  • Cliff Wells at Apr 2, 2002 at 5:46 pm

    On 01 Apr 2002 21:56:44 -0500 nbecker at 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.

    --
    Cliff Wells, Software Engineer
    Logiplex Corporation (www.logiplex.net)
    (503) 978-6726 x308 (800) 735-0555 x308
  • Tobias Klausmann at Apr 3, 2002 at 8:08 am

    Cliff Wells wrote:
    On 01 Apr 2002 21:56:44 -0500
    nbecker at 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 at Apr 3, 2002 at 7:43 pm
    On 3 Apr 2002 08:08:18 GMT, Tobias Klausmann wrote:
    :Cliff Wells wrote:
    :> On 01 Apr 2002 21:56:44 -0500
    :> nbecker at 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 :-)

    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 at Apr 3, 2002 at 8:03 pm

    Mats Wichmann wrote:
    On 3 Apr 2002 08:08:18 GMT, Tobias Klausmann
    wrote:

    :Cliff Wells wrote:
    :> On 01 Apr 2002 21:56:44 -0500
    :> nbecker at 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
  • Michael Hudson at Apr 3, 2002 at 9:40 pm

    Tobias Klausmann <klausman-un030402 at 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.

    Cheers,
    M.
  • Andy Gimblett at Apr 4, 2002 at 10:08 am

    On Wed, Apr 03, 2002 at 09:40:45PM +0000, Michael Hudson wrote:
    Tobias Klausmann <klausman-un030402 at 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?

    --
    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 at Apr 5, 2002 at 9:28 am

    Andy Gimblett <gimbo at ftech.net> writes:
    On Wed, Apr 03, 2002 at 09:40:45PM +0000, Michael Hudson wrote:
    Tobias Klausmann <klausman-un030402 at 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 at Apr 5, 2002 at 10:01 am

    On Fri, Apr 05, 2002 at 09:28:02AM +0000, Michael Hudson wrote:
    Andy Gimblett <gimbo at 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

    --
    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.
  • Cliff Wells at Apr 3, 2002 at 8:20 pm

    On 3 Apr 2002 08:08:18 GMT Tobias Klausmann wrote:
    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.

    --
    Cliff Wells, Software Engineer
    Logiplex Corporation (www.logiplex.net)
    (503) 978-6726 x308 (800) 735-0555 x308
  • Mats Wichmann at Apr 3, 2002 at 7:43 pm
    On 01 Apr 2002 21:56:44 -0500, nbecker at 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.


    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
  • Chris Barker at Apr 5, 2002 at 9:08 pm

    Mats Wichmann wrote:
    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

    Chris.Barker at noaa.gov

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedApr 1, '02 at 5:31a
activeApr 5, '02 at 9:08p
posts15
users10
websitepython.org

People

Translate

site design / logo © 2022 Grokbase