Thread: Postgresql & Python 2
Kind of an odd issue, I think....
I compiled the source rpm on my redhat 7.1 system and then installed the
resulting RPMS (including the python modules). Worked. No problems.
But redhat 7.1 comes stock with python 1.5.2. For various reasons, I've
upgraded to Python 2.1, which DOESN'T replace python 1.5, but, rather,
installs the new version along side. In other words:
/usr/lib/python1.5
/usr/lib/python2
The postgres drivers are in /usr/lib/python1.5/site-packages.
Let's suppose I want to delete python1.5. If a reinstall the
posgres-python rpm, it'll put 'em back in /usr/lib/python1.5. How do I
get them into the python2 directory?
I'm recompiling the rpms out of the source rpm (for posgres) as I write
this, but suddenly realize that it won't make any difference, as python
1.5 is used by too many system utilities to be excised from my system.
My guess was that the build process would detect the newer python, at
least of the old one was absent.)
SO, what's the best way to get the postgres modules into the python 2
hierarchy? Just look at the RPM in question and copy 'em over, as in
copy the following files to the python2 hierarchy?
/usr/lib/python1.5/site-packages/_pgmodule.so
/usr/lib/python1.5/site-packages/pg.py
/usr/lib/python1.5/site-packages/pgdb.py
/usr/lib/python1.5/site-packages/setup.py
I'll try to get some code working doing this tomorrow night when I get
home from work, but I'm curious to know before hand if there are known
problems.
Thanks!
Keith
Keith F Irwin <kirwin14@home.com> writes: > Kind of an odd issue, I think.... > > I compiled the source rpm on my redhat 7.1 system and then installed the > resulting RPMS (including the python modules). Worked. No problems. > > But redhat 7.1 comes stock with python 1.5.2. For various reasons, I've > upgraded to Python 2.1, which DOESN'T replace python 1.5, but, rather, > installs the new version along side. In other words: > > /usr/lib/python1.5 > /usr/lib/python2 > > The postgres drivers are in /usr/lib/python1.5/site-packages. > > Let's suppose I want to delete python1.5. If a reinstall the > posgres-python rpm, it'll put 'em back in /usr/lib/python1.5. How do I > get them into the python2 directory? Don't move them - python 1.5 and python 2 aren't binary compatible. What you can do, is to hardcode the pyver variable on top of the file. -- Trond Eivind Glomsrød Red Hat, Inc.
> > Let's suppose I want to delete python1.5. If a reinstall the
> > posgres-python rpm, it'll put 'em back in /usr/lib/python1.5. How do I
> > get them into the python2 directory?
> Don't move them - python 1.5 and python 2 aren't binary compatible.
> What you can do, is to hardcode the pyver variable on top of the file.
Trond--
I hate to be ignorant, but what do you mean? You're talking about the
fact that they _pgmodule.so is incompatible?
What does it mean to hardcode the pyver variable on top of the file? If
I've got a database.py file with database classes, and I include this
file in main.py, which instantiates its objects and calls its methods,
how to I run main.py with Python2, and Database.py with Python1.5?
I'll see if I can find something in the python library reference, as
soon as I can get to it.
Might this work for me?
http://www.bel-epa.com/pyapache/Python/postgresql-python/
If so, I'll have to figure out how to hack that myself... ;)
Keith
> --
> Trond Eivind Glomsrød
> Red Hat, Inc.
Keith F Irwin writes: > But redhat 7.1 comes stock with python 1.5.2. For various reasons, I've > upgraded to Python 2.1, which DOESN'T replace python 1.5, but, rather, > installs the new version along side. In other words: > > /usr/lib/python1.5 > /usr/lib/python2 This is a bug in the RPM packages, which our maintainer has evidently neglected to fix. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Keith F Irwin <kirwin14@home.com> writes: > > > Let's suppose I want to delete python1.5. If a reinstall the > > > posgres-python rpm, it'll put 'em back in /usr/lib/python1.5. How do I > > > get them into the python2 directory? > > > Don't move them - python 1.5 and python 2 aren't binary compatible. > > > What you can do, is to hardcode the pyver variable on top of the file. > > Trond-- > > I hate to be ignorant, but what do you mean? You're talking about the > fact that they _pgmodule.so is incompatible? Yes. > What does it mean to hardcode the pyver variable on top of the file? Look at the specfile, and you'll see the an attempt to autodetect the version of python installed. You can hardcode the result... > If I've got a database.py file with database classes, and I include > this file in main.py, which instantiates its objects and calls its > methods, how to I run main.py with Python2, and Database.py with > Python1.5? You can't. > -- Trond Eivind Glomsrød Red Hat, Inc.
> > What does it mean to hardcode the pyver variable on top of the file? > > Look at the specfile, and you'll see the an attempt to autodetect the > version of python installed. You can hardcode the result... AH! The Spec file! Okay, THAT I get. :) Excellent. That'll work nicely. Keith > > > If I've got a database.py file with database classes, and I include > > this file in main.py, which instantiates its objects and calls its > > methods, how to I run main.py with Python2, and Database.py with > > Python1.5? > > You can't. > > > > -- > Trond Eivind Glomsrød > Red Hat, Inc.
Peter Eisentraut <peter_e@gmx.net> writes: > Keith F Irwin writes: > > > But redhat 7.1 comes stock with python 1.5.2. For various reasons, I've > > upgraded to Python 2.1, which DOESN'T replace python 1.5, but, rather, > > installs the new version along side. In other words: > > > > /usr/lib/python1.5 > > /usr/lib/python2 > > This is a bug in the RPM packages, which our maintainer has evidently > neglected to fix. Exactly what bug are you thinking of? The current build process tries to detect your current version of python and build for that.. -- Trond Eivind Glomsrød Red Hat, Inc.
On Friday 13 July 2001 12:20, Peter Eisentraut wrote: > Keith F Irwin writes: > > But redhat 7.1 comes stock with python 1.5.2. For various reasons, I've > > upgraded to Python 2.1, which DOESN'T replace python 1.5, but, rather, > > installs the new version along side. In other words: > > /usr/lib/python1.5 > > /usr/lib/python2 > This is a bug in the RPM packages, which our maintainer has evidently > neglected to fix. :-/ Reread the spec file. The version of python that answers to the command 'python' will indeed be handled correctly while rebuilding the source RPM. This was fixed a while back. Although I could improve the finding of the path to python instead of hardcoding that. However, note that the _default_shipped_Red_Hat-7.1_ doesn't have python 2.x installed by default -- the python2 packages on Powertools does that. I build binaries for the default _Red_Hat_-7.1_ only. Incidentally, Mandrake 8.0 ships with Python 2.x -- and the source RPM rebuilds fine there (thanks to Justin Clift). The SOURCE RPM can handle any single python version that's installed. Yes, _single_ -- there are way too many customizations that are possible to make it worthwhile to support multiple versions installed . So, to answer Keith's question -- if you want Python 2 modules, you will either need to do what Trond suggested (editing %pyver and hardcoding its definition to '2.0' (or 2.1)), or making sure the command 'python' points to python2. Or edit the pyver definition line to use python2 by default. Is there a need for a whole separate binary RPM for Python 2 clients? But I will reiterate that the prebuilt binary RPMs are built for _stock_ RedHat (and hopefully the systems used to build the non-RedHat binaries are stock, as well). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > But I will reiterate that the prebuilt binary RPMs are built for _stock_ > RedHat (and hopefully the systems used to build the non-RedHat binaries are > stock, as well). Maybe the directory naming on the ftp site should indicate this. For instance, I see v7.1-Mandrake, that's clear. But what about the rest (could be the question of a user)? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
On Friday 13 July 2001 14:47, Peter Eisentraut wrote: > Lamar Owen writes: > > But I will reiterate that the prebuilt binary RPMs are built for _stock_ > > RedHat (and hopefully the systems used to build the non-RedHat binaries > > are stock, as well). > Maybe the directory naming on the ftp site should indicate this. For > instance, I see v7.1-Mandrake, that's clear. But what about the rest > (could be the question of a user)? Currently the tree is: /pub/binary/v7.1.2/RPMS/SRPMS /pub/binary/v7.1.2/RPMS/redhat-7.0 /pub/binary/v7.1.2/RPMS/redhat-6.2 /pub/binary/v7.1.2/RPMS/mandrake-8.0 /pub/binary/v7.1.2/RPMS/redhat-7.1 /pub/binary/v7.1.2/RPMS/mandrake-7.2 /pub/binary/v7.1.2/RPMS/mandrake-7.1 Is there improvement yet to be made? Is my structure 'upside-down' (actually, this is the structure Marc started me on.....and I have continued....)? -- Lamar Owen
Trond Eivind Glomsrød writes: > Exactly what bug are you thinking of? > > The current build process tries to detect your current version of > python and build for that.. The RPMs Lamar distributed had Python 1.5 hardcoded. If you fixed that in the meantime, my apologies. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter