[Twisted-Python] SQL ORM for Twisted & PostgreSQL?

Glyph glyph at twistedmatrix.com
Wed Jul 24 16:43:31 MDT 2013


On Jul 24, 2013, at 11:05 AM, exarkun at twistedmatrix.com wrote:

> On 05:43 pm, glyph at twistedmatrix.com wrote:
>> On Jul 23, 2013, at 12:12 AM, Hynek Schlawack <hs at ox.cx> wrote:
>>> What exactly do you mean? Sounds like you’d like it to got straight into Twisted? Wouldn’t it make more sense to release it separately first? You know, kind of http://www.codinghorror.com/blog/2013/07 /rule-of-three.html
>> 
>> That's also a possibility, but following that rule makes the assumption that Calendar Server is just one application, when it's at least two (calendar & contacts) ;-).
>>> We could move it into the twisted namespace though.
>> 
>> The main motivation to do this, especially with adbapi2, is because Twisted already has an implementation of this exact thing with some deficiencies.
> 
> As far as I can tell, there's nothing stopping Hynek from grabbing all the code and releasing it as a separate project.
> 
> It seems like this would get the ball rolling more quickly and I don't see the downside.  If anything, having it as an independent project is more likely to get more people interested in it more quickly and so increase the pool of people who might be interested in addressing whatever concerns need to be addressed for its inclusion in Twisted.
> 
> So, why block that work in favor of inclusion directly in Twisted?
> 
> Jean-Paul

In principle I can see the appeal of spinning out small, lightweight projects to test enhancements to Twisted, but my enthusiasm for this idea has been tempered over time by the fact that it has never actually worked (that I can recall).  How many projects on <https://launchpad.net/tx> have ever made it to be features within Twisted?  Remember how we weren't going to work on our own process pooling implementation because <https://launchpad.net/ampoule> was going to solve that problem, and we'd just include it when it was done?  As far as I know we haven't even managed to pull in small things like <https://github.com/dreid/treq/blob/master/treq/client.py#L57>.

First of all, there's change-tracking overhead.  People interested in ADBAPI would now have 3 places to potentially put code: Hynek's hypothetical project, calendarserver.org, and Twisted.  Twisted code-reviewers are probably not going to look at Hynek's project (they hardly look at Twisted at it is), and that means that it might have a laxer approach to cool new features, which in turn means that "more interest" just means that it's going to be a bigger ball of code that is harder to get re-integrated.  Calendar Server developers are going to keep maintaining the version in the Calendar Server repository, so it's going to diverge.  Everybody's using a different source tree, so merging will all have to be done manually.

Then there's the fact that provenance tracking is a pain.  Let's say Hynek makes a new project on Github.  The license clearly gives him the right to do that.  Now, when people contribute to that repository, who are they contributing to?  Hynek, or Twisted, or Calendar Server (or Github?)?  What license are they providing those modifications under, Apache2 or MIT?

This is all totally possible to keep track of and deal with, and indeed, if I don't have the time to be responsive to Hynek I'd recommend that he go ahead and do so; I'm sure we can work it out later if we need to.  But preparing it for contribution to Twisted is just an engineering headache under a simple, established licensing and contribution process, and given the option between an engineering headache and a licensing headache PLUS an engineering headache PLUS a process headache, I'll take the engineering headache every time. ;-)

If you just want to see broader testing first, a better solution would be for Hynek to just contribute to the Calendar Server project directly so that there are effectively 2 parties involved rather than 3; for starters, we could have a setup.py in the calendarserver.org repository that just submits twext.enterprise.* to PyPI as an independent source distribution, while remaining part of the same project.  It can *appear* to be a separate project as long as it's developed in the same place. :-)

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20130724/afa5fc11/attachment-0002.html>


More information about the Twisted-Python mailing list