[Twisted-Python] Tubes! (package metadata and version constraints)

[exarkun at twistedmatrix.com]

On 10 Jul, 08:37 pm, glyph at twistedmatrix.com wrote:
>
>On Jul 10, 2014, at 12:32 PM, exarkun at twistedmatrix.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.

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.

Jean-Paul