Open Stack

Hi,

I would say, use a separated virtual environment in devstack - without
the --system-site-packages switch, of course, and set it up as a user.
Install the packages that are needed in order to be able to pip install
them (like libxslt-dev). It's a development environment. I think my
email is equivalent to a +1 to (Monty's change + virtualenv).

Mate

On Tue, Aug 06, 2013 at 10:29:14AM -0500, Dean Troyer wrote:
> On Tue, Aug 6, 2013 at 3:50 AM, Bob Ball <bob.ball at citrix.com> wrote:
> > I think we need a further constraint:
> >
> > We must ensure that yum/etc believes that the python-* packages are installed.
> 
> If we want the rest of the system to use them, yes.
> 
> > If we want to install a newer version of the python-* packages then we have to make sure the package manager for the OS knows that they are installed.
> 
> Or knows to ignore them.  By keeping them away from the places the
> package manager is likely to overwrite them with older versions.
> Sounds like a venv?  Because it is, a
> global-always-available-never-needs-explicit-acvtivation venv:
> /usr/local
> 
> > In my mind this restricts us to having to do something with RPMs - whether that is packaging all of the python components up as RPMs or using the dummy RPM proposed by Ian.
> 
> The packaging work is already being done (will be done) for each
> platform that wants to ship OpenStack.  It just isn't up-to-date with
> development cycles.
> 
> > Out of these two, I think the cleanest solution for us is to use the dummy RPM for RPMs that we explicitly remove.  If this is only python-lxml and python-crypto (and maybe a couple of others) then this is probably fine.
> >
> > One final thought - if we have to jump through lots of hoops to get this working correctly in devstack, then should we re-evaluate the use of virtual environments?  We're looking at departing a long way from how this can be deployed in the real world - so perhaps virtual environments would be a useful way to encapsulate what we're testing?
> 
> venvs, as implemented by the current tools, doesn't work well here.
> BUT, if there was a single global venv available that could override
> rpm-installed packages at will without disturbing them, would that
> work?
> 
> BTW, that's how Debian/Ubuntu do it.  pip installs to /usr/local and
> sys.path has it ahead of /usr
> 
> >> * Fedora and RHEL6 have a nasty configuration of telling pip to
> >> install packages into the same location as RPM-installed packages
> >> setting up hard-to-diagnose problems and irritating sysadmins
> >> everywhere.  FTR, Debian/Ubuntu configure pip to install into
> >> /usr/local and put '/usr/local/lib/python2.7/dist-packages' ahead of
> >> '/usr/lib/python2.7/dist-packages' in sys.path.
> 
> I guess what I am saying is that if we're going to 'trick' something
> on the system to behaving the way that we want, let's do the right
> trick that doesn't have to be continually maintained.
> 
> dt
> 
> -- 
> 
> Dean Troyer
> dtroyer at gmail.com
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Mate Lakat