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
Attachment:
pgp7EnAfInp8o.pgp
Description: PGP signature
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
