Hi everyone, Recently, wrapt was added as a dependency. The Python module suffers from obvious design issues, like for example: - Lack of Python 3.4 support - Broken with Python 3.2 - Upstream sources in "src" instead of "wrapt" so then running py.test doesn't work unless you do "ln -s src wrapt", and then "PYTHONPATH=. py.test tests" to run the tests. - Unit tests not included in the pypi module
That'd be fine, if upstream was comprehensive, and willing to fix things. It seems like he's going to approve our patches for Python 3.2 and 3.4. But ... There's an embedded copy of six.py in the code. I've been trying to convince upstream to remove it, and provided a patch for it. But it's looking like upstream simply refuses to remove the embedded copy of six.py. This means that, on each new upstream release, I may have to rebase my Debian specific patch to remove the copy. See comments here: https://github.com/GrahamDumpleton/wrapt/pull/24 I've still packaged and uploaded the module to Debian, but the situation isn't great with upstream, which doesn't seem to understand, which will inevitably lead to more (useless) work for downstream distros. So I'm wondering: are we being careful enough when selecting dependencies? In this case, I think we haven't, and I would recommend against using wrapt. Not only because it embeds six.py, but because upstream looks uncooperative, and bound to its own use cases. In a more general case, I would vouch for avoiding *any* Python package which is embedding a copy of another one. This should IMO be solved before the Python module reaches our global-requirements.txt. Thoughts anyone? Cheers, Thomas Goirand (zigo) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev