Python threading - some ports depend on it, others break with it

[Jim Stapleton]

> I'm having so much trouble with this. I'm hosting a trac based project
> which is implemented in python and uses an sqlite db backend along with
> its python bindings. Now it turns out that pysqlite breaks badly
> (compiles and installs fine but chokes on import, see
> http://lists.initd.org/pipermail/pysqlite/2006-May/000553.html) if
> python itself is compiled *without threading* support.
>
> However, on the same box I run a postgresql development and testing
> database and we have some triggers and other functions implemented in
> pl/python. Guess what? The compile of postgresql-plpython chokes upon
> configure if python is built *with threading* support. Running it seems
> to work fine, but there's a reason upstream put this check into
> configure because supposedly this is known to break things.
...
> I need both of these ports on one box and I'm not sure what to do to
> sort out this mess properly. Any ideas? What's up with Python's
> threading support on FreeBSD in any case, why is is broken?

I would suggest framing either some of the programs/libraries with a
few counts of 1st degree murder, and sending it to jail for life,
where it can run for life in a nice little cell with it's own pet
python.

Would that work? It's probably a bit more work than a desirable
solution, but if you don't need them running in the same "space", it
should work. Or have I completely missed the point (very likely given
me).

-Jim Stapleton