On 10 Jul, 08:37 pm, firstname.lastname@example.org wrote:
On Jul 10, 2014, at 12:32 PM, email@example.com wrote:
- As a separate Python package, the logistics of actually using tubes
are simpler (just consider how you might declare a dependency on a branch of Twisted - keeping in mind you may want to use tubes in a project that already depends on some version of Twisted). It may not make sense to say that it is the same quality as Twisted proper right off the bat (on the other hand, it may well - I suspect tubes in its current form actually is a lot higher quality than large sections of Twisted) but that doesn't mean people (not to mention the tubes project) can't benefit from being able to experiment with it.
I would love it if there were a way to release a package in an actually experimental state, and not just have the release of a package implicitly tell people that it's time to put it into production and demand long-term support for it. Quick sanity check: go run 'pip freeze' in a production virtualenv you're running - what percentage of the version numbers that come back start with a zero? I will bet a significant amount of money that it's not 0% :-).
As it stands, if you're not willing to use a random outdated branch of Twisted with unknown bugs that may change without warning, you're probably not willing to adopt Tubes yet.
I think you missed part of my point here.
I want to try tubes and see if they make my application simpler or better or faster or whatever. My application depends on Twisted >= 14.0.0. It doesn't matter how or why: that's what the metadata says and I can't use an older version of Twisted unless I do a bunch of stupid package/distribution related hacking that I don't want to do. *So* much of the Python tooling has now moved to requiring and respecting explicit dependency declarations that trying to side-step these now is a significant hassle. Separating tubes from Twisted solves this problem.
It's not at all a question of whether the code is stable or production ready or even works at all, it's a matter of packaging constraints.