Open Stack

On 10/31/2012 01:03 PM, Kiall Mac Innes wrote:
> On Wed, Oct 31, 2012 at 12:57 PM, Pádraig Brady <P at draigbrady.com <mailto:P at draigbrady.com>> wrote:
>
>     [...SNIP...]
>
>     One of the action items from there is:
>
>     * freeze 'sane' version (max major version?) range at release time
>
>     So by recording the max version in the pip-requires,
>     it would mean that newer versions wouldn't be pulled
>     in, in the future, that might break stuff.
>     Also distros etc. should not be impacted since packages
>     manage dependencies independently.
>
>
> This is not necessarily true, for example:
>
> $ cat /usr/lib/python2.7/dist-packages/python_novaclient-2.9.0.17.g05bbe0f.egg-info/requires.txt
> httplib2
> iso8601>=0.1.4
> prettytable>=0.6,<0.7
> simplejson
>
> $ dpkg -S /usr/lib/python2.7/dist-packages/python_novaclient-2.9.0.17.g05bbe0f.egg-info/requires.txt
> python-novaclient: /usr/lib/python2.7/dist-packages/python_novaclient-2.9.0.17.g05bbe0f.egg-info/requires.txt
>
> Any *other* python package that both depends on novaclient and uses entry points to load code via `pkg_resources` will validate those requirements.
>
> I was bitten by this with keystone yesterday, as mentioned in my previous mail on this thread.

That's a packaging issue I think, and ideally should be handled there.

Python managed dependencies are usually redundant and problematic
in a distro packaging context (unless they're explicitly managed
to cater for parallel installed versions). For example today I
removed a python managed dependency from the python-websockify
rpm package which was causing issues:

http://pkgs.fedoraproject.org/cgit/python-websockify.git/commit/?id=75108db54

cheers,
Pádraig.