On Mar 19, 2014, at 10:18 AM, Kurt Griffiths <kurt.griffi...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev