[openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages
dtroyer at gmail.com
Tue Aug 6 15:19:10 UTC 2013
On Mon, Aug 5, 2013 at 8:37 PM, Ian Wienand <iwienand at redhat.com> wrote:
> I think Anvil is working with the package management system so that
> scenario doesn't happen. The "fine, those can be re-installed with
> pip" bit is where the problem occurs.
> The "whole lot" bit is important, because you can't have conflicts
> there. Say requirements.txt brings in setuptools-0.9.8; Anvil will
> create a python-setuptools 0.9.8 package. If rpm-packaged nose relies
> *exactly* python-setuptools at 0.6.10, there will be a conflict -- I
> think the installation would fail to complete. But likely, that
> package doesn't care and gets it dep satisfied by 0.9.8 
How many times has that bitten us already just in the PyPI world?
> Because you're not using pip to install directly, you don't have this
> confusion around who owns files in /usr/lib/python2.6/site-packages
> and have rpm or pip overwriting each other -- RPM owns all the files
> and that's that.
I agree that is the way the world is supposed to work. I wore the
sysadmin hat for far longer than I care to admit and spent a lot of
time building packages to fix things like this. That's easy for stuff
that is released every 1-2 years. For the rate of churn we have it is
>> Removing python-setuptools will also remove python-nose, numpy and
>> other packages depending on what is installed.
> Nowhere is python-setuptools removed; just upgraded.
That example refers to the current path of removing python-setuptools
and replacing it with a version installed from source.
>  From a quick look at Anvil I don't think it would handle this
> situation, which is probably unsolvable (if a rpm-package wants one
> version and devstack wants another, and it all has to be in
> /usr/lib/python2.6/site-packages, then *someone* is going to lose).
And that is the crux of the problem. When both can be installed
side-by-side and sys.path is in control of the order, things work.
This is such a fundamental problem in the distro that I am beginning
to thing that we need to address it ourselves. Everything else is
dtroyer at gmail.com
More information about the OpenStack-dev