[Twisted-Python] TX project guidelines (was Re: Twisted service kit)

Phil Christensen phil at bubblehouse.org
Fri Jun 13 15:20:42 EDT 2008

On Jun 13, 2008, at 1:26 PM, Kevin Horn wrote:
> On Fri, Jun 13, 2008 at 12:07 PM, Phil Christensen <phil at bubblehouse.org 
> > wrote:
>> The great thing about the Twisted Community Code project is that  
>> you don't need any particular approval from anyone to add your  
>> code. If you think what you have might be of use to someone,  
>> whether it's for production use or just as a learning tool, you  
>> should consider creating a TX subproject.
>> There are other options as well. If you feel your code doesn't  
>> warrant the overhead of a full project (e.g., you don't see  
>> yourself having time to respond to bug requests or create  
>> blueprints, etc.), you should be able to create a personal Bazaar  
>> branch to store your code in, which you can then assign to the TX  
>> superproject.
>> This probably won't get as many eyeballs, since it won't be on the  
>> subproject list, but it's a good way to get your code out there in  
>> an easily accessible place. Plus, given the nature of Bazaar,  
>> anyone who wishes will be able to work with your code in their own  
>> branch.
>> -phil
> BTW, Phil, are there any established guidelines/conventions for the  
> "TX" packages other than "start your project name with a 'tx'"?

Not really. Even the 'tx' prefix is just a suggestion. I think adding  
the prefix is a good idea if your project has a generic name, like a  
protocol, but it's up to you. Using it is a nice show of 'community  
solidarity', but I know I have a couple of projects I hope to add soon  
where it would just look or sound weird.

> Any suggestions or guidelines on how such packages should leverage  
> setuptools, stuff like that?
> I think it would be very useful to have all of these packages  
> install in a similar fashion, though of course, it wouldn't be  
> practical (or advisable) to try and enforce this in any way.  But I  
> do think it would be good to have a set of guidelines posted  
> someplace saying "here is the recommended way to set up a TX package".

Agreed. I think deployment options like this are best decided on a per- 
project basis, since TX will hopefully be a home for example code and  
works-in-progress as well as true project releases.

Still, I think we can all agree that projects should be installable  
using distutils at the very least. The key thing here is that for most  
projects you should be able to "python setup.py install" and be done  
with it.

Does anyone have any other suggestions? If we can come up with a list  
of suggested criteria, I'll write up a spec to add to the TX blueprints.


More information about the Twisted-Python mailing list