I downloaded PyLucene 0.98 for Linux (Fedora Core 3) and was disappointed to see that I couldn't use the binary packages because my python was built with UCS4 characters and the package assumed UCS2. (At least, this is my theory based on the error message and the resulting web search.)
Could be. I do not know what determines the size of unicode characters on the various builds of python but I did notice that it could vary :)
PyLucene makes no assumption in the size of unicode chars, in particular, it doesn't assume that it matches libgcj/java's usual 16 bit size.
The binaries for PyLucene on Linux are currently built on a Gentoo 2004.3 system. I would not assume that they're usable anywhere else.
So I went to build it from source. A couple comments:
1. I don't want to edit the Makefile. When I'm building things from source, I prefer to build them automatically via script so I can consume new source code by running the same script. Is there any reason PyLucene can't use distutils? It's pretty standard, much more convenient for the user, and solves problems 2 and 3.
Well, PyLucene's Makefile is currently 924 lines long. I do not know (I assume not) that distutils can do everything that the Makefile does. It was suggested earlier that a distutils script could wrap the 'make' task. If that is indeed possible and if that distutils script could also pass the correct env vars values to the Makefile, then editing the Makefile would no longer be necessary and that would be progress indeed. Patches are welcome :)
2. I don't want to install the package in the site-packages directory in my global python package directory, I want to install it in a special directory where I'm putting all the packages built for my application. That way, I don't need to do all this stuff as root. With distutils, I could just run setup.py --home=$MY_BETTER_DIRECTORY With the makefile, I had to trick it by setting PREFIX_PYTHON=/usr and then doing make install PREFIX_PYTHON=$MY_BETTER_DIRECTORY
True enough. If you don't run 'make install' but just 'make', you should be fine and be able to copy the files in release manually. Alternatively, that distutils task could also take care of it. Like I said, patches are more than welcome.
3. When I build that way, I get warnings about security providers:import PyLuceneWARNING: could not properly read security provider files: file:/usr/lib/python2.4/site-packages/security/libgcj.security file:/usr/lib/python2.4/site-packages/security/classpath.security Falling back to standard GNU security provider The .security files are present in the right place relative to the directory that I installed in, but apparently the wrong paths are hard-coded somewhere. Based on what's in these files, I think the warning doesn't matter, but it'd be nice if whatever gcj was doing with these files could be configured to be relative to the installation prefix, which as per 1 and 2 shouldn't have to be the same as the Python interpreter installation prefix.
Yes, this has been a long time irritation. I kludged it by assuming _PyLucene.so would be installed in site-packages. If that is not the case, then this needs to be fixed in the %init block of PyLucene.i around line 4255.
The distutils task could probably also parametrize this for PyLucene.i
Andi.. _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
