On July 10, 2014 at 3:40:26 PM, Glyph Lefkowitz (firstname.lastname@example.org) wrote:
On Jul 10, 2014, at 12:32 PM, email@example.com wrote:
2) 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.
For what it’s worth, if you add an “a%n” to the end of a version, pip won’t install it unless you specify the version exactly. e.g., “tubes” version “0.1a1” won’t be found if you type “pip install tubes”, only “pip install tubes==0.1a1”.