Open Stack

On Mar 19, 2014, at 10:18 AM, Kurt Griffiths <kurt.griffiths at rackspace.com> wrote:

> Thierry Carrez wrote:
> 
>> There was historically a lot of deviation, but as we add more projects
>> that deviation is becoming more costly.
> 
> I totally understand the benefits of reducing the variance between
> projects, and to be sure, I am not suggesting we have 10 different
> libraries to do X.  However, as more projects are added, the variety of
> requirements also increases, and it becomes very difficult for a single
> library to meet all the projects' needs without some projects having to
> make non-trivial compromises.
> 
> One approach to this that I’ve seen work well in other communities is to
> define a small set of options that cover the major use cases.
> 
>> My question would be, can Pecan be improved to also cover Marconi's use
>> case ? Could we have the best of both worlds (an appropriate tool *and*
>> convergence) ?
> 
> That would certainly be ideal, but as always, the devil is in the details.
> 
> Pecan performance has been improving, so on that front there may be an
> opportunity for convergence (assuming webob also improves in performance).
> However, with respect to code paths and dependencies, I am not clear on
> the path forward. Some dependencies could be removed by creating some kind
> of “pecan-light” library, but that would need to be done in a way that
> does not break projects that rely on those extra features. That would
> still leave webob, which is an often-used selling point for Pecan. I am
> not confident that webob can be modified to address Marconi and Swift's
> needs without making backwards-incompatible changes to the library which
> would obviously not be acceptable to the broader Python community.

I’m not sure that “number of dependencies” is a useful metric at all tbh. At the
very least it’s not a very telling metric in the way it was presented in the review.
An example -> A tool that has to safely render untrusted HTML, you could do
it with nothing but the stdlib using say regex based parsers (and get it wrong) or
you could depend on bleach which depends on html5lib. Using the “number of
dependencies” metric the first would be considered the superior method
however it’s deeply flawed.

The reason given in the report is that more dependencies = larger attack surface,
but that’s not really accurate either. Often times you’ll find that if two libraries
solve the same problems, one with dependencies and one without the one
without dependencies has a less battle tested reimplementation of whatever
functionality the other library has a dependency for.

In order to accurately assess the impact of dependencies you have to understand
what the library is using those dependencies for, how well tested those dependencies
are, what the release cycle and backwards compatibility policy of those dependencies
are, and what the other project is doing in place of a dependency for the feature(s)
that depend on them (which the answer may be that it doesn’t have that feature,
and then you have to decide if that feature is useful to you and if you’ll need to add
a dependency or write less battle tested code in order to get it).

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140319/25e6f036/attachment.pgp>