I've been looking recently at getting the diablo release of openstack running on RHEL6.2 beta with support from EPEL. The current status is that I have nova and glance services running and passing very basic tests. I'm using 2 packages not yet in EPEL though.
python-webob: 0.9.6 in RHEL6.2, 1.0.8 in F1[56] python-sqlalchemy: 0.5.5 in RHEL6.2, 0.6.8 in F15
The RHEL6.2 versions of these packages are too old to support openstack. Now it's not practical to update those for RHEL6.2 and I've requested consideration for RHEL6.3. In the meantime I think it's probably best to have parallel installable versions of those packages in EPEL, given EPEL's mandate of not updating RHEL packages: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies So we might have a python-webob10 package in EPEL, and adjust the openstack packages accordingly. There is precedent for this in packages like python-sphinx10
I will consider again adjusting openstack to be directly compatible with the RHEL6.2 versions of these packages, but on first look, that approach seems quite invasive.
Another outstanding task which should be completed soon is to support libguestfs as a means to update guest images. openstack uses NBD currently but that is unavailable in RHEL6 as it was supplanted by iSCSI. NBD is a little hacky anyway so this should be a better approach: https://bugs.launchpad.net/nova/+bug/719325
To test these changes I'm using the instructions from: https://fedoraproject.org/wiki/Test_Day:2011-10-20_OpenStack_Test_Day Some config changes were required over that done for Fedora 16:
SELinux This works in F16 but I'm not worrying about it for the moment in RHEL # setenforce 0 # sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
qpidd and matahari These services may be enabled by default in some RHEL6.2 releases, and conflict at the TCP port level at least. I guess we could put rabbitmq on a different port, and there was talk about qpidd being used over amqpd, but for now I did: for svc in matahari-broker matahari-host matahari-network \ matahari-service matahari-sysconfig qpidd; do service $svc stop chkconfig $svc off done
nova-manage db sync I needed to run the above before I could start openstack-nova-* services. TODO: check whether that needs to be run at install time.
There are issues with RHEL6 running VM running VMs themselves, which was one of the test modes for the F16 test day above. For now all testing is done on bare metal.
cheers, Pádraig.
Hey Pádraig,
(cc-ed some likely suspects who might be interested in our plight :)
On Mon, 2011-11-14 at 22:28 +0000, Pádraig Brady wrote:
I've been looking recently at getting the diablo release of openstack running on RHEL6.2 beta with support from EPEL. The current status is that I have nova and glance services running and passing very basic tests.
Awesome!
I'm using 2 packages not yet in EPEL though.
python-webob: 0.9.6 in RHEL6.2, 1.0.8 in F1[56] python-sqlalchemy: 0.5.5 in RHEL6.2, 0.6.8 in F15
The RHEL6.2 versions of these packages are too old to support openstack. Now it's not practical to update those for RHEL6.2 and I've requested consideration for RHEL6.3. In the meantime I think it's probably best to have parallel installable versions of those packages in EPEL, given EPEL's mandate of not updating RHEL packages: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies So we might have a python-webob10 package in EPEL, and adjust the openstack packages accordingly. There is precedent for this in packages like python-sphinx10
Right, the approach python-sphinx10 is using is documented here:
https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions
Also, I double checked with some #epel folks on the conflicts policy. See the discussion below.
So, yeah - this sounds like our own real option
Cheers, Mark.
<markmc> hey; anyone here with time to discuss EPEL's policy on packages with conflict with RHEL? <rdieter> markmc: the policy is fairly clear and simple.... don't. what did you wish to discuss? <markmc> rdieter: heh :) <markmc> the situation is this <markmc> we're adding OpenStack to EPEL6 <markmc> it went into F-16 recently <markmc> it requires a newer version of python-webob than is in RHEL6 <markmc> now, I had assumed we could add e.g. python-webob10 with a Conflicts: python-webob <markmc> sort of the opposite of a compat package <markmc> but that's verboten? <rdieter> sounds like you have 2 options: 1. file RFE asking RHEL to update it <markmc> 1. is done, will be in RHEL 6.3 <markmc> (hopefully) <markmc> (in 6+ months, I guess) <wolfy> markmc: conflict with core is verboten <rdieter> 2. create something the aforementioned python-web10 ,but it must be parallel-installable without conflict <markmc> okay, so it would install into e.g. site-packages/webob10 or something ? <markmc> i.e. no file or package level conflicts ? <wolfy> markmc: right <rdieter> markmc: something like that, yes <markmc> ok, at least we have an option :) <markmc> thanks guys
On Tue, Nov 15, 2011 at 03:16:19PM +0000, Mark McLoughlin wrote:
Hey Pádraig,
(cc-ed some likely suspects who might be interested in our plight :)
On Mon, 2011-11-14 at 22:28 +0000, Pádraig Brady wrote:
I've been looking recently at getting the diablo release of openstack running on RHEL6.2 beta with support from EPEL. The current status is that I have nova and glance services running and passing very basic tests.
Awesome!
I'm using 2 packages not yet in EPEL though.
python-webob: 0.9.6 in RHEL6.2, 1.0.8 in F1[56] python-sqlalchemy: 0.5.5 in RHEL6.2, 0.6.8 in F15
The RHEL6.2 versions of these packages are too old to support openstack. Now it's not practical to update those for RHEL6.2 and I've requested consideration for RHEL6.3. In the meantime I think it's probably best to have parallel installable versions of those packages in EPEL, given EPEL's mandate of not updating RHEL packages: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies So we might have a python-webob10 package in EPEL, and adjust the openstack packages accordingly. There is precedent for this in packages like python-sphinx10
Right, the approach python-sphinx10 is using is documented here:
https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions
Also, I double checked with some #epel folks on the conflicts policy. See the discussion below.
So, yeah - this sounds like our own real option
Yep. It's not too hard to package parallel installable versions. Getting software to use it is the hard part. You can use setuptools to set python to find the correct versions (which is the recommendations in the guidelines I believe). The drawback is that setuptools is stupid about things sometimes so you might get errors that you have problems figuring out unless you have experience with it (I can help with that if you need it). You can also manually set python's path (Either PYTHONPATH as an environment variable or sys.path inside of python itself) to find the correct module directory. The setuptools way looks something like this:
# The next section is not needed in most cases but in some cases, like using # mod_wsgi to load a wsgi script this may be necessary try: from __main__ import __requires__ except ImportError: __main__.__requires__ == [] __requires__ = __main__.__requires__ else: if isinstance(basestring, __requires__): __requires__ = [__requires__]
# This is where you add the parallel installable version __requires__.append('SQLAlchemy >= 0.6')
# This is where you import pkg_resources. pkg_resources sets up the proper # python paths when you import it for the first time. Unless you look at # funny. Or talk bad about its mother import pkg_resources # This next one probably isn't necessary since we used __requires__ above # Note that the pkg_resources docs only talk about the call talked about # next but it's entirely inadequate for the job. pkg_resources.require('SQLAlchemy >= 0.6')
import sqlalchemy
# Should print 0.6.? print sqlalchemy.__version__
This is the way it looks modifying sys.path yourself. Note that you have to change it when the python-sqlalchemy package is updated if you do it this way and you use the easy_install recipe from the guidelines to install the compat sqlalchemy package::
import sys sys.path.insert(0, '/usr/lib64/python2.7/site-packages/SQLAlchemy-0.7.1-py2.7.egg') import sqlalchemy print sqlalchemy.__version__
I've also attempted to create sqlalchemy0.6 and sqlalchemy0.7 packages in the past. Both fail to build on RHEL6 right now. You'll have to look at the unittests. With sqlalchemy 0.7, at least some of the unittests looked like genuine failures (rather than simply needing updates to the unittests).
-Toshio
On 11/16/2011 12:53 AM, Toshio Kuratomi wrote:
Yep. It's not too hard to package parallel installable versions. Getting software to use it is the hard part. You can use setuptools to set python to find the correct versions (which is the recommendations in the guidelines I believe). The drawback is that setuptools is stupid about things sometimes so you might get errors that you have problems figuring out unless you have experience with it (I can help with that if you need it). You can also manually set python's path (Either PYTHONPATH as an environment variable or sys.path inside of python itself) to find the correct module directory. The setuptools way looks something like this:
# The next section is not needed in most cases but in some cases, like using # mod_wsgi to load a wsgi script this may be necessary try: from __main__ import __requires__ except ImportError: __main__.__requires__ == [] __requires__ = __main__.__requires__ else: if isinstance(basestring, __requires__): __requires__ = [__requires__]
# This is where you add the parallel installable version __requires__.append('SQLAlchemy >= 0.6')
# This is where you import pkg_resources. pkg_resources sets up the proper # python paths when you import it for the first time. Unless you look at # funny. Or talk bad about its mother import pkg_resources # This next one probably isn't necessary since we used __requires__ above # Note that the pkg_resources docs only talk about the call talked about # next but it's entirely inadequate for the job. pkg_resources.require('SQLAlchemy >= 0.6')
import sqlalchemy
# Should print 0.6.? print sqlalchemy.__version__
This is the way it looks modifying sys.path yourself. Note that you have to change it when the python-sqlalchemy package is updated if you do it this way and you use the easy_install recipe from the guidelines to install the compat sqlalchemy package::
import sys sys.path.insert(0, '/usr/lib64/python2.7/site-packages/SQLAlchemy-0.7.1-py2.7.egg') import sqlalchemy print sqlalchemy.__version__
Thanks for the tips Toshio!!
I've also attempted to create sqlalchemy0.6 and sqlalchemy0.7 packages in the past. Both fail to build on RHEL6 right now. You'll have to look at the unittests. With sqlalchemy 0.7, at least some of the unittests looked like genuine failures (rather than simply needing updates to the unittests).
Yes it's awkward. Here are my rebuild notes for 0.6.8 on RHEL 6.2
python-nose is not new enough to build. The correct version wasn't specified in the spec though and the resultant error crashed RHEL once: https://bugzilla.redhat.com/show_bug.cgi?id=753505 I hacked together an updated python-nose to allow running sqlalchemy %checks which passed, but then disabled the %checks so as not to need a newer python-nose (and the newer packages it in turn needs to be built with).
In case it's of use, you can find the RHEL python-sqlalchemy-0.6.8 packages I was testing with, here http://www.pixelbeat.org/openstack/
cheers, Pádraig.
On Wed, Nov 16, 2011 at 10:09:36AM +0000, Pádraig Brady wrote:
Yes it's awkward. Here are my rebuild notes for 0.6.8 on RHEL 6.2
python-nose is not new enough to build. The correct version wasn't specified in the spec though and the resultant error crashed RHEL once: https://bugzilla.redhat.com/show_bug.cgi?id=753505 I hacked together an updated python-nose to allow running sqlalchemy %checks which passed, but then disabled the %checks so as not to need a newer python-nose (and the newer packages it in turn needs to be built with).In case it's of use, you can find the RHEL python-sqlalchemy-0.6.8 packages I was testing with, here http://www.pixelbeat.org/openstack/
Cool. Will Openstack work with SQLAlchemy0.7? I ask because I'm always looking for ways to reduce work and if we can use the latest SQLAlchemy that will mean we don't have to maintain both python-sqlalchemy0.6 and python-sqlalchemy0.7 packages down the road.
About unittests, we probably want to either disable just the specific unittests or add a compat package with the newer versions of nose. RHEL6 seems to include 0.10.4 and the current version is 1.1.2. I can see the newer version being useful to people doing work with it (although they'll need to modify their behaviour slightly; using /usr/bin/nosetests-1.1, for instance.) Not sure if running nosetests-1.1 will be sufficient to use the correct nose module or if we'd have to also set PYTHONPATH to point at the correct version of nose explicitly. Worth a try at least.
-Toshio
On 11/16/2011 05:42 PM, Toshio Kuratomi wrote:
On Wed, Nov 16, 2011 at 10:09:36AM +0000, Pádraig Brady wrote:
Yes it's awkward. Here are my rebuild notes for 0.6.8 on RHEL 6.2
python-nose is not new enough to build. The correct version wasn't specified in the spec though and the resultant error crashed RHEL once: https://bugzilla.redhat.com/show_bug.cgi?id=753505 I hacked together an updated python-nose to allow running sqlalchemy %checks which passed, but then disabled the %checks so as not to need a newer python-nose (and the newer packages it in turn needs to be built with).
In case it's of use, you can find the RHEL python-sqlalchemy-0.6.8 packages I was testing with, here http://www.pixelbeat.org/openstack/
Cool. Will Openstack work with SQLAlchemy0.7? I ask because I'm always looking for ways to reduce work and if we can use the latest SQLAlchemy that will mean we don't have to maintain both python-sqlalchemy0.6 and python-sqlalchemy0.7 packages down the road.
Yes it probably makes sense to jump to 0.7.
Mark McLoughlin fixed a load of migration issues with 0.7 (F16) and pushed those fixes upstream, so it should work.
Note I'm testing with getting openstack to monkey patch sqlalchemy, which avoids epel having to host an updated version of this package. It is quite a small patch at present. There are risks we'll hit bugs fixed between 0.5.5 and 0.6.6 (the main version openstack is tested with), but it's worth a try.
About unittests, we probably want to either disable just the specific unittests or add a compat package with the newer versions of nose. RHEL6 seems to include 0.10.4 and the current version is 1.1.2. I can see the newer version being useful to people doing work with it (although they'll need to modify their behaviour slightly; using /usr/bin/nosetests-1.1, for instance.) Not sure if running nosetests-1.1 will be sufficient to use the correct nose module or if we'd have to also set PYTHONPATH to point at the correct version of nose explicitly. Worth a try at least.
Note %check in newer python-nose has further dependencies outside of RHEL, which I disabled when building my hacked up version.
cheers, Pádraig.
On Wed, Nov 16, 2011 at 06:20:14PM +0000, Pádraig Brady wrote:
On 11/16/2011 05:42 PM, Toshio Kuratomi wrote:
About unittests, we probably want to either disable just the specific unittests or add a compat package with the newer versions of nose. RHEL6 seems to include 0.10.4 and the current version is 1.1.2. I can see the newer version being useful to people doing work with it (although they'll need to modify their behaviour slightly; using /usr/bin/nosetests-1.1, for instance.) Not sure if running nosetests-1.1 will be sufficient to use the correct nose module or if we'd have to also set PYTHONPATH to point at the correct version of nose explicitly. Worth a try at least.
Note %check in newer python-nose has further dependencies outside of RHEL, which I disabled when building my hacked up version.
I've created a sample python-nose1.1 package. I have no idea whether it will work as expected or not, though. If you want to test it with your python-sqlalchemy packages and it works, I'll submit it for package review.
http://toshio.fedorapeople.org/packages/
I'm also not sure if I should be creating python-nose1.1 or python-nose1 packages -- I plan on asking upstream nose about how they plan to manage version numbers and compatibility if these packages will actually work for our usecase.
-Toshio
2011/11/16 Pádraig Brady P@draigbrady.com:
python-nose is not new enough to build. The correct version wasn't specified in the spec though and the resultant error crashed RHEL once: https://bugzilla.redhat.com/show_bug.cgi?id=753505 I hacked together an updated python-nose to allow running sqlalchemy %checks which passed, but then disabled the %checks so as not to need a newer python-nose (and the newer packages it in turn needs to be built with).
I'm happy to tackle some of these python dependencies within EPEL. If you can add what's needed to http://fedoraproject.org/wiki/OpenStack
I'll take a few. Looking now on this page there looks to be nothing that needs reviewing or anything or am I missing something?
Steve.
On 11/16/2011 07:11 PM, Steve Traylen wrote:
2011/11/16 Pádraig Brady P@draigbrady.com:
python-nose is not new enough to build. The correct version wasn't specified in the spec though and the resultant error crashed RHEL once: https://bugzilla.redhat.com/show_bug.cgi?id=753505 I hacked together an updated python-nose to allow running sqlalchemy %checks which passed, but then disabled the %checks so as not to need a newer python-nose (and the newer packages it in turn needs to be built with).
I'm happy to tackle some of these python dependencies within EPEL. If you can add what's needed to http://fedoraproject.org/wiki/OpenStack
I'll take a few. Looking now on this page there looks to be nothing that needs reviewing or anything or am I missing something?
I've just updated the wiki page with the latest info. Really all that's left to be done is python-{webob,sqlalchemy} updates (though there may be other packages that pop up as testing progresses). However, the exact course is not fully decided yet, as I'm testing lots of combinations locally to see which is best to commit.
We also have to do the NBD to libguestfs change. https://bugzilla.redhat.com/show_bug.cgi?id=734727
Note I'm currently using RHEL6.2 beta for testing, so if using an earlier (derived) distro you might hit issues I have not. I'm currently doing the following steps to setup a RHEL system (note testing in a RHEL VM is not currently supported).
* service qpidd stop; chkconfig qpidd off * setenforce 0 * enable the epel-testing repo * yum install the RPMs from http://www.pixelbeat.org/openstack/rhel/ * yum install python-tempita * yum install openstack-nova openstack-glance * Follow setup instructions and test cases from: https://fedoraproject.org/wiki/Test_Day:2011-10-20_OpenStack_Test_Day
I will keep the wiki up to date as I fix stuff.
thanks! Pádraig.
On 11/16/2011 09:52 PM, Pádraig Brady wrote:
On 11/16/2011 07:11 PM, Steve Traylen wrote:
2011/11/16 Pádraig Brady P@draigbrady.com:
python-nose is not new enough to build. The correct version wasn't specified in the spec though and the resultant error crashed RHEL once: https://bugzilla.redhat.com/show_bug.cgi?id=753505 I hacked together an updated python-nose to allow running sqlalchemy %checks which passed, but then disabled the %checks so as not to need a newer python-nose (and the newer packages it in turn needs to be built with).
I'm happy to tackle some of these python dependencies within EPEL. If you can add what's needed to http://fedoraproject.org/wiki/OpenStack
I'll take a few. Looking now on this page there looks to be nothing that needs reviewing or anything or am I missing something?
I've just updated the wiki page with the latest info. Really all that's left to be done is python-{webob,sqlalchemy} updates (though there may be other packages that pop up as testing progresses). However, the exact course is not fully decided yet, as I'm testing lots of combinations locally to see which is best to commit.
Well monkey patching sqlalchemy and webob was getting too invasive, so it looks like we'll have to add python-webob1.0 and python-sqlalchemy0.7 packages to epel. Steve, feel free to tackle webob1.0 (1.0.8). If not I'll do it after I submit python-sqlalchemy0.7 (0.7.3) (after confirming here first).
cheers, Pádraig.
p.s. for my own reference I've attached the BigInteger monkey patch which might be otherwise useful, which I was using from glance.registry.db.bigint
2011/11/17 Pádraig Brady P@draigbrady.com:
packages to epel. Steve, feel free to tackle webob1.0 (1.0.8). If not I'll do it after I submit python-sqlalchemy0.7 (0.7.3) (after confirming here first).
The latest is 1.1.1 http://pypi.python.org/pypi/WebOb
this is better choice I guess unless there is a reason? python-webob11 for a package name.
Steve.
On Thu, Nov 17, 2011 at 09:12:25PM +0100, Steve Traylen wrote:
2011/11/17 Pádraig Brady P@draigbrady.com:
packages to epel. Steve, feel free to tackle webob1.0 (1.0.8). If not I'll do it after I submit python-sqlalchemy0.7 (0.7.3) (after confirming here first).
The latest is 1.1.1 http://pypi.python.org/pypi/WebOb
this is better choice I guess unless there is a reason? python-webob11 for a package name.
Just a note: python-webob1.1 would be better (packaging guidelines were recently updated to allow dots in package names for this purpose.). You can ask the upstream if they have any backwards compatibility to version number policies as well. Sometimes when a project goes to 1.0 and beyond, they change their versioning policies so that major number releases are all compatible. Other times they stick with the minor number since they've gotten used to it throughout their 0.x development.
-Toshio
On Thu, Nov 17, 2011 at 10:26 PM, Toshio Kuratomi a.badger@gmail.com wrote:
ust a note: python-webob1.1 would be better (packaging guidelines were recently updated to allow dots in package names for this purpose.). You can ask the upstream if they have any backwards compatibility to version number policies as well. Sometimes when a project goes to 1.0 and beyond, they change their versioning policies so that major number releases are all compatible. Other times they stick with the minor number since they've gotten used to it throughout their 0.x development.
Hi, I've just posted python-webobj10 which is 1.0.8.
https://bugzilla.redhat.com/show_bug.cgi?id=754848
I don't seem to be able to edit the wiki page.
Steve.
On 11/17/2011 09:50 PM, Steve Traylen wrote:
On Thu, Nov 17, 2011 at 10:26 PM, Toshio Kuratomi a.badger@gmail.com wrote:
ust a note: python-webob1.1 would be better (packaging guidelines were recently updated to allow dots in package names for this purpose.). You can ask the upstream if they have any backwards compatibility to version number policies as well. Sometimes when a project goes to 1.0 and beyond, they change their versioning policies so that major number releases are all compatible. Other times they stick with the minor number since they've gotten used to it throughout their 0.x development.
Hi, I've just posted python-webobj10 which is 1.0.8.
Excellent thanks. I'll try this out tomorrow. You did name the package correctly as "webob" rather than "webobj" as you typoed above :) One thing I would adjust is s/10/1.0/
About using v1.1.1, I think it's better to align with what's used in Fedora, rather moving ahead to the lastest and "greatest". This will be a relatively short lived package in any case, as we'll probably be updating the package proper in RHEL 6.3
I don't seem to be able to edit the wiki page.
I've just updated the wiki there: https://fedoraproject.org/wiki/OpenStack#OpenStack_in_EPEL
You should be able to also, if you have a fedora account. One thing I noticed is that you need to shift-refresh on a wiki page after login, for editing links to be apparent.
cheers, Pádraig.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/17/2011 03:58 PM, Pádraig Brady wrote:
You should be able to also, if you have a fedora account. One thing I noticed is that you need to shift-refresh on a wiki page after login, for editing links to be apparent.
Be sure you are using HTTPS. If you are going over HTTP, the page is the anonymous read-only view. Either log in or add the 'S' to the URL.
- - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41
On Thu, Nov 17, 2011 at 11:58:54PM +0000, Pádraig Brady wrote:
On 11/17/2011 09:50 PM, Steve Traylen wrote:
I don't seem to be able to edit the wiki page.
I've just updated the wiki there: https://fedoraproject.org/wiki/OpenStack#OpenStack_in_EPEL
You should be able to also, if you have a fedora account. One thing I noticed is that you need to shift-refresh on a wiki page after login, for editing links to be apparent.
Usually (always in my experience) you can click on View Source and it will actually take you to the edit page. There's been a bug since we upgraded mediawiki in infrastructure and we haven't been able to track it down... probably need to find a better mediawiki admin than we have available.
-Toshio
On 11/17/2011 09:50 PM, Steve Traylen wrote:
On Thu, Nov 17, 2011 at 10:26 PM, Toshio Kuratomi a.badger@gmail.com wrote:
ust a note: python-webob1.1 would be better (packaging guidelines were recently updated to allow dots in package names for this purpose.). You can ask the upstream if they have any backwards compatibility to version number policies as well. Sometimes when a project goes to 1.0 and beyond, they change their versioning policies so that major number releases are all compatible. Other times they stick with the minor number since they've gotten used to it throughout their 0.x development.
Hi, I've just posted python-webobj10 which is 1.0.8.
I'm reviewing the above.
I've posted python-sqlalchemy0.7-0.7.3-2 here: https://bugzilla.redhat.com/show_bug.cgi?id=755065 Review swap?
I've built local glance and nova packages against the above 2 compat packages and initial tests are passing. I'm commit the openstack updates soon.
cheers, Pádraig.
On 11/16/2011 12:53 AM, Toshio Kuratomi wrote:
Yep. It's not too hard to package parallel installable versions. Getting software to use it is the hard part. You can use setuptools to set python to find the correct versions (which is the recommendations in the guidelines I believe). The drawback is that setuptools is stupid about things sometimes so you might get errors that you have problems figuring out unless you have experience with it (I can help with that if you need it). You can also manually set python's path (Either PYTHONPATH as an environment variable or sys.path inside of python itself) to find the correct module directory. The setuptools way looks something like this:
# The next section is not needed in most cases but in some cases, like using # mod_wsgi to load a wsgi script this may be necessary try: from __main__ import __requires__ except ImportError: __main__.__requires__ == [] __requires__ = __main__.__requires__ else: if isinstance(basestring, __requires__): __requires__ = [__requires__]
# This is where you add the parallel installable version __requires__.append('SQLAlchemy >= 0.6')
# This is where you import pkg_resources. pkg_resources sets up the proper # python paths when you import it for the first time. Unless you look at # funny. Or talk bad about its mother import pkg_resources # This next one probably isn't necessary since we used __requires__ above # Note that the pkg_resources docs only talk about the call talked about # next but it's entirely inadequate for the job. pkg_resources.require('SQLAlchemy >= 0.6')
import sqlalchemy
# Should print 0.6.? print sqlalchemy.__version__
This is the way it looks modifying sys.path yourself. Note that you have to change it when the python-sqlalchemy package is updated if you do it this way and you use the easy_install recipe from the guidelines to install the compat sqlalchemy package::
import sys sys.path.insert(0, '/usr/lib64/python2.7/site-packages/SQLAlchemy-0.7.1-py2.7.egg') import sqlalchemy print sqlalchemy.__version__
For the record I needed to dig a little deeper into pkg_resources to get it to use the egg I wanted, rather than the system default. I've attached the notes on this that I'm including with python-sqlalchemy0.7. I will merge to https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions if it proves robust.
cheers, Pádraig.
On Mon, 2011-11-14 at 22:28 +0000, Pádraig Brady wrote:
There are issues with RHEL6 running VM running VMs themselves, which was one of the test modes for the F16 test day above. For now all testing is done on bare metal.
To clarify this a bit more for folks - the issue is that non-KVM qemu isn't supported on RHEL6, so you can't run plain qemu VM's inside a RHEL6 VM.
Cheers, Mark.
-
Karsten Wade -
Mark McLoughlin -
Pádraig Brady -
Steve Traylen -
Toshio Kuratomi