My .pythonrc.py
Friday, May 16th, 2008#!/usr/bin/env python
print "hellooooooooooo"
import rlcompleter, readline
readline.parse_and_bind('tab: complete')
del rlcompleter, readline
#!/usr/bin/env python
print "hellooooooooooo"
import rlcompleter, readline
readline.parse_and_bind('tab: complete')
del rlcompleter, readline
This ended up being a hassle, for two reasons: 1) out of date build instructions in the subversion source, 2) their instructions may not work if you have multiple subversion installations. I learned a teensy bit of python troubleshooting along the way so jotting this down ….
First, building subversion:
./configure --with-apxs=/usr/sbin/apxs # to build apache mods
--with-swig
Note: in step 2 of subversion-1.4.3/subversion/bindings/swig/INSTALL, I got misled thinking the libsvn_swig_py.so should be there at this step. It shouldn’t. In fact, it won’t be even after step 3, but step 3 does build a similarly named file.
From here out the build was as advertised:
make swig-py
make check-swig-py
make install-swig-py # switched to root for this step
Second, the install. The problem I had was that I had two versions of subversion installed (on purpose, for compatibility with an old repository on the same server). Unfortunately I was picking up the wrong version of the subversion bindings.
This is what subversion says to do, seems reasonable enough:
$ echo /usr/local/lib/svn-python
> /usr/lib/python2.x/site-packages/subversion.pth
But…when python parses .pth files, it places them at the end of sys.path, rather than the position of the directory containing the .pth file. So even though I set PYTHONPATH=/usr/lib/python2.4/site-packages, sys.path ended up with that directory at the head, and /usr/local/lib/svn-python at the tail. Aaargh.
Sounds easy, but it took me a while to figure this all out. I learned:
Some odd design decisions for python re scope. I gotta think more about this, but I’m groggy.