Kevin Ar18 wrote:
> Based on that, I guess my question is what would it have taken to have
> picked one of BSD/MIT projects and working with those people instead?
> In other words, what key things affected the decision for psycopg?
> What areas is it so far ahead in or that would have just been too much
> work to fix in the other implementations?
A lot of it as I see it is plain old fashioned popularity resulting from
long sustained development. psycopg has been around since 2001, the
current version is already compatible with SQLAlchemy, Django, Zope,
PyDO, and it's integral to the large Python/PostgreSQL toolchain from
Skype including tools like Londiste. When something is supported in
that many places, and the main complaints are its license and
documentation rather than its code, I know I'm not going to start by
assuming I should just hack on somebody else's code to try and replace
it just because their license is a little better. And I'd consider
BSD/MIT only a little better than the LGPL.
That sort of bad decision making is how we got to so many abandoned
Python drivers in the first place. If everybody who decided they were
going to write their own from scratch had decided to work on carefully
and painfully refactoring and improving PyGreSQL instead, in an
incremental way that grew its existing community along the way, we might
have a BSD driver with enough features and users to be a valid
competitor to psycopg2. But writing something shiny new from scratch is
fun, while worrying about backward compatibility and implementing all
the messy parts you need to really be complete on a project like this
isn't, so instead we have a stack of not quite right drivers without any
broad application support.
(Aside: I have a bit of vocabulary I regularly use for this now.
Open-source projects that just ignore working on an existing stack of
working implementations, to instead start from scratch to build
something of questionably improved fanciness instead regardless of its
impact on backward compatibility and the existing userbase, have in my
terminology "PulseAudioed" the older projects).
The gauntlet I would throw down for anyone who thinks there's a better
approach here is to demonstrate a driver that has working support going
back to Python 2.4 for any two of the apps on my list above. Get even
that much of a foothold, and maybe the fact that yours is more Pythonic,
cleaner, or better licensed matters. Until then, working apps have to
be the primary motivation for what to work on here, unless there's a
really terrible problem with the driver. The existing psycopg license
and the web site issues were in combination enough to reach that level
of total issues for a number of people. With the news from Federico
that a license improvement is approaching and signs of major
documentation improvements, that problem seems like it will soon be
solved as far as I'm concerned. When someone manages to make their
alternative driver a prerequisite for an app I need, only at that point
will that driver show back up on my radar.
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
In response to
pgsql-hackers by date
|Next:||From: Euler Taveira de Oliveira||Date: 2010-02-11 04:21:24|
|Subject: Re: Postgres Triggers issue|
|Previous:||From: Tom Lane||Date: 2010-02-11 04:07:57|
|Subject: Re: Avoiding bad prepared-statement plans. |