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 <[email protected]> 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 > [email protected] > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mate Lakat _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
