Open Stack

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 <zigo at debian.org>
Organization: Debian
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: Thursday, May 29, 2014 at 2:25 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at 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 at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev