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. Kurt _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
