On Tue, 2 Mar 2010, Bill Janssen wrote:
I'm updating my build scripts for Linux. It's a bit tricky, because I'm
installing all the Python modules in a separate spot,
/opt/uplib-1.7.9/lib[64]/python[2.5,2.6,2.7]/[site,dist]-packages/,
depending on the Linux distro and machine architecture. Call it SITEDIR.
I'm trying not to affect the user's installed non-UpLib Python modules.
To build PyLucene properly, I install a patched version of setuptools in
that location, as well, and use that version of setuptools to build
PyLucene. It's tricky, because setuptools out of the box doesn't seem
to grok the lib/lib64 and site/dist differences, and usually tries to
install in the wrong place. So I patch the setuptools sources, then
build an egg (python setup.py bdist_egg), then run "sh" on the egg,
specifying the --install-dir switch, to get setuptools into the correct
spot.
Then I build JCC, and install it into SITEDIR.
Then I try to build PyLucene. That's where I run into difficulty. I
setenv PYTHONPATH to SITEDIR, and invoke "make" like this (in this case):
export python=/usr/bin/python
export PYTHONPATH=${SITEDIR}
export JCCCOMMAND="${python} -m jcc"
make PREFIX_PYTHON=/usr ANT=ant PYTHON=${python} JCC="${JCCCOMMAND}" NUM_FILES=1
which gives me this:
/usr/bin/python -m jcc --shared --jar
lucene-java-2.9.1/build/lucene-core-2.9.1.jar --jar
lucene-java-2.9.1/build/contrib/snowball/lucene-snowball-2.9.1.jar --jar
lucene-java-2.9.1/build/contrib/analyzers/common/lucene-analyzers-2.9.1.jar
--jar lucene-java-2.9.1/build/contrib/regex/lucene-regex-2.9.1.jar --jar
lucene-java-2.9.1/build/contrib/memory/lucene-memory-2.9.1.jar --jar
lucene-java-2.9.1/build/contrib/highlighter/lucene-highlighter-2.9.1.jar --jar
lucene-java-2.9.1/build/contrib/queries/lucene-queries-2.9.1.jar --jar
lucene-java-2.9.1/build/contrib/instantiated/lucene-instantiated-2.9.1.jar
--jar build/jar/extensions.jar --package java.lang java.lang.System
java.lang.Runtime --package java.util java.util.Arrays
java.text.SimpleDateFormat --package java.io java.io.StringReader
java.io.InputStreamReader java.io.FileInputStream --exclude
org.apache.lucene.queryParser.Token --exclude
org.apache.lucene.queryParser.TokenMgrError --exclude
org.apache.lucene.queryParser.Que
ry
ParserTokenManager --exclude org.apache.lucene.queryParser.ParseException
--exclude org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude
org.apache.regexp.RegexpTunnel --python lucene --mapping
org.apache.lucene.document.Document
'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties
'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence
org.apache.lucene.search.Hits 'length:()I'
'doc:(I)Lorg/apache/lucene/document/Document;' --rename
org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer --version
2.9.1 --module python/collections.py --files 1 --build
Traceback (most recent call last):
File "/usr/lib/python2.5/runpy.py", line 95, in run_module
filename, loader, alter_sys)
File "/usr/lib/python2.5/runpy.py", line 52, in _run_module_code
mod_name, mod_fname, mod_loader)
File "/usr/lib/python2.5/runpy.py", line 32, in _run_code
exec code in run_globals
File
"/usr/lib/python2.5/site-packages/JCC-1.9-py2.5-linux-i686.egg/jcc/__init__.py", line
28, in <module>
cpp.jcc(sys.argv)
File
"/usr/lib/python2.5/site-packages/JCC-1.9-py2.5-linux-i686.egg/jcc/cpp.py",
line 340, in jcc
raise ValueError, "Invalid argument: %s" %(arg)
ValueError: Invalid argument: --rename
make: *** [compile] Error 255
You'll notice that what's happening is that I'm not loading the JCC (2.4.1) from
SITEDIR; instead, I'm loading an old one (1.9) from the system location. Why
is this? I thought it might be due to setuptools, but I can't reproduce this
Maybe it is because Python picks stuff from site-packages first ? (not sure)
I think this whole mess would be a lot simpler if you used virtualenv.py.
http://pypi.python.org/pypi/virtualenv
It lets you do what you're trying to do - install stuff without affecting a
user's install, yet override some of their libs in a special place
inheriting from their setup otherwise if you so choose.
Once you've created a virtual env, what is picked up depends on the python
executable invoked - the one in the virtual env or the system one - and
involves no messing with env vars at all.
Andi..