Open Stack

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