Hi thomas, Since I'm the one that added wrapt to the requirements list I thought it would be appropriate for me to respond :)
So looking over the pull request it seems like there was agreement that the issues will be fixed and the adjustments will occur (that seems to be the case last time I checked it). So that¹s good news and I'd like to thank you for bringing these issues up to the author (who seemed like he required a little educating about what to do here, which is just how this works, aka, teaching others and explaining are as much of being part of the community as anything else). So I'm thankful u worked through that and it seems to be going aok there (correct me if I am misreading it). As for why I pulled it in (incase u are wondering). Wrapt allows for a single decorator to be aware of whether its being applied to a instance method, a non-instance method, a static method (or even on-top of a class) using a single decorator. This imho has been one of the painful things that is lacking with python decorators and made it hard to make a *single* depreciation decorator (the review for taskflow for this is @ https://review.openstack.org/#/c/87055/) that doesn't require specialization for each possible type of decorator type (a depreciation decorator for methods, another one for functions, another one for...). So wrapt seems to solve this which makes it imho really nice 'syntax sugar' for solving this problem. So that was my usage of it (the review still isn't in yet, soon I hope). If u feel that others need to jump on that pull request or talk to the author, maybe we should work through this instead of just 'abandoning ship' first. Since I am pretty sure this won't be our time that we have to 'teach' others good practices to help them improve their own code. Btw the six inclusion seems to actually be a statement the six authors seem to endorse so I'm not sure I can blame others for just following that endorsement (even if it's not really good practice to copy code around). "Six supports every Python version since 2.5. It is contained in only one Python file, so it can be easily copied into your project. (The copyright and license notice must be retained.)" (from https://pypi.python.org/pypi/six) -----Original Message----- From: Thomas Goirand <z...@debian.org> Organization: Debian Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Thursday, May 29, 2014 at 2:25 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: [openstack-dev] Selecting more carefully our dependencies >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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
