Open Stack

On 05/29/2014 05:25 PM, Thomas Goirand wrote:
> 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)

It's looking like I misunderstood upstream, and that he's going to do
something about the embedded six.py. However, what's above still stands
for the general case.

Thomas