On Tue, Aug 6, 2013 at 3:50 AM, Bob Ball <bob.b...@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 dtro...@gmail.com _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
