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

[Gunther Mayer]

Hi guys,

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.

Chicken and egg - one of my ports insists on python with threads 
enabled, the other port insists I use python without thread support. My 
workaround is to compile python without threading, install(or upgrade) 
postgresql-plpython, then recompile python with threading, install(or 
upgrade) trac and pray that plpython won't eat my dog when I use it. A 
really painful and error prone exercise, especially when an upgrade 
comes along (security or otherwise).

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?

To get you an idea of what versions I'm running, the affected postgresql 
ports are

postgresql-plpython-8.2.6
postgresql-server-8.2.6

for the trac dependencies the involved culprits are:

py25-pysqlite-2.0.7_1
python25-2.5.1_1
python-2.5,2
sqlite-3.3.8 # peripheral

I remember with python 2.4 I had the same endless issues over a year ago 
so it's not 2.5's fault. Oh, and btw, I'm running 6.2-RELEASE-p9 i386.

Gunther