openstack in EPEL status

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20111115/ed27f996/attachment.sig>