LuckyDonkey

While setting up a new FreeBSD 7.0 server I found that psycopg 2.0.7 doesn't easy_install on FreeBSD. It's because of a configuration problem in config.h at the bottom.

#if defined(__FreeBSD__) || (defined(_WIN32) && !defined(__GNUC__)) || defined(__sun__)
/* what's this, we have no round function either? */
static double round(double num)
{
  return (num >= 0) ? floor(num + 0.5) : ceil(num - 0.5);
}
#endif
 

However 'round' is defined in FreeBSD and has been since FreeBSD 5.3 (according to the manual page). The fix is simple, just remove the 'defined(__FreeBSD__) ||' part of the '#if' and you should be fine. Now you can 'easy_install .' psycopg2.

PS: I'd tried to raise a ticket but http://www.initd.org/ trac seems to have been down for ages.

I upgraded a test server to FreeBSD 6.3 (released a few days ago) and all was working well apart from my TurboGears app. I run a TurboGears instance behind mod_wsgi and it wouldn't start. Here is the error I got in http_errors.log

[Sat Jan 19 11:32:42 2008] [error] [client 207.155.93.149] mod_wsgi (pid=1292): Exception occurred within WSGI script '/home/m/release1.0/apache/turbogears.wsgi'.
[Sat Jan 19 11:32:42 2008] [error] [client 207.155.93.149] Traceback (most recent call last):
[Sat Jan 19 11:32:42 2008] [error] [client 207.155.93.149]   File "/home/m/release1.0/apache/turbogears.wsgi", line 67, in <module>
[Sat Jan 19 11:32:42 2008] [error] [client 207.155.93.149]     import turbogears
[Sat Jan 19 11:32:42 2008] [error] [client 207.155.93.149] ImportError: No module named turbogears

That's odd. I've not uninstalled TurboGears and my background processes that #import TurboGears still work. Infact if I go to the python command line and type #import TurboGears it all works... bugger.

To complicate matters (in this case) I use a workingenv to contain a very specific version of TurboGears and all of it's dependencies. In order for the wsgi script to access the sandbox environment I use an excellent script which tweaks the runtime environment to include the paths in a working env. My first though is that something here had gone wrong. So I turned to prints and some basic error capture.

# Load all distributions into the working set.
from pkg_resources import working_set, Environment
 
env = Environment(root)
env.scan()
 
distributions, errors = working_set.find_plugins(env)
for dist in distributions:
    working_set.add(dist)

Printing out errors revealed:

errors:
{Amara 1.2.0.2 (/usr/home/m/tgenv1_0_32/lib/python2.5/Amara-1.2.0.2-py2.5.egg):
   DistributionNotFound(Requirement.parse('4Suite-XML>=1.0.2'),),
TGCaptcha 0.11 (/usr/home/m/tgenv1_0_32/lib/python2.5/TGCaptcha-0.11-py2.5.egg):
   DistributionNotFound(Requirement.parse('pycrypto>=2.0.1'),)}

Well I hadn't uninstalled those packages and I'm pretty sure that freebsd-update hadn't uninstalled them so where the hell have they gone! Looking in the workingenv sandbox package directory

ls -la /usr/home/m/tgenv1_0_32/lib/python2.5
4Suite_XML-1.0.2-py2.5-freebsd-6.2-RELEASE-i386.egg
Amara-1.2.0.2-py2.5.egg
BeautifulSoup-3.0.5-py2.5.egg
Cheetah-2.0.1-py2.5-freebsd-6.2-RELEASE-i386.egg
Cheetah-2.0rc8-py2.5-freebsd-6.2-RELEASE-i386.egg
CherryPy-2.2.1-py2.5.egg
...
PasteScript-1.3.6-py2.5.egg
PyProtocols-1.0a0dev_r2302-py2.5-freebsd-6.2-RELEASE-i386.egg
Routes-1.7.1-py2.5.egg
RuleDispatch-0.5a0.dev_r2306-py2.5-freebsd-6.2-RELEASE-i386.egg
SQLAlchemy-0.3.10-py2.5.egg
...
moved_aside_site.py
psycopg2-2.0.6-py2.5-freebsd-6.2-RELEASE-i386.egg
pycrypto-2.0.1-py2.5-freebsd-6.2-RELEASE-i386.egg
python_dateutil-1.3-py2.5.egg
...
setuptools.pth
simplejson-1.7.3-py2.5-freebsd-6.2-RELEASE-i386.egg
...
 

BUGGER, there are packages in there with the OS version number in that need to be updated:

easy_install -U amara
easy_install -U pycrypto
easy_install -U psycopg2
...

fixed all the problems and finally the site is up again So I've fixed the problem but I don't know why my other processes and the python command line worked. If anyone knows, I love to know too. Cheers.

Working with TurboGears is usually a breeze. But when it comes to installation thing never seem to go too well. Firstly do you run the tg_setup.py the project provides or easy_install TurboGears it? Why do you need to run the installer twice sometimes? There are answers in the mailing list to these questions but the fact these questions are asked gives me the willies.

I'm not having a go at the maintainers of the project. They are always extra helpful on the mailing list and to be fair if it really bothers me that much why don't I just fix it myself. I'm sad to say I can't be bothered, I've got more important things to do and I'm sure the maintainers have made the same decision.

Anyway, today I ran across a new one and couldn't find a solution via google so I'm offering up this snippet to the search engine in the sky.

After installing most of TurboGears I went to install Routes. I used easy_install but it didn't work.

 
easy_install "Routes >= 1.7"
Searching for Routes>=1.7
Reading http://pypi.python.org/simple/Routes/
Reading http://routes.groovie.org/
Best match: Routes 1.7.1
Downloading http://pypi.python.org/packages/source/R/Routes/
  Routes-1.7.1.tar.gz#md5=89cdc61ae803dc151c338ddd85551478
Processing Routes-1.7.1.tar.gz
Running Routes-1.7.1/setup.py -q bdist_egg --dist-dir
  /tmp/easy_install-6ZoHjg/Routes-1.7.1/egg-dist-tmp-GXYrHm
Traceback (most recent call last):
 
...
 
  File "/usr/local/tgmetalinfo/tgenv/lib/python2.5/
   setuptools-0.6c7-py2.5.egg/setuptools/sandbox.py", line 29, in <lambda>
    {'__file__':setup_script, '__name__':'__main__'}
  File "setup.py", line 1, in <module>
ImportError: No module named ez_setup
 

The first thing that struck me is that ez_setup is part of the setup tools package so how can it not be imported. To complicate things more I'm using workingenv which dicks about with your PYTHONPATH to create a sandbox.

After poking about on the easy_install site I found the answer in the docs. I created a file (in the current working directory) like this:

 
[easy_install]
 
# set the default location to install packages
install_dir = CWD/ENVIRONMENT FOLDER/lib/python2.5
 

where CWD and ENVIRONMENT FOLDER are replaced with your workingenv library path. Now the install works.

I think all of this has something to so with workingenv not creating a site-packages folder inside lib/python2.5 and something somewhere expecting it. Anyway, it all works for me now. Hope this helps.

PS: I know working env is deprecated in favour of virtualenv but I ran in to the same problem with virtualenv