Open Stack

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)