OK thanks Andi, +1 to release! (minor comments below) Mike
On Sat, Nov 7, 2009 at 1:49 PM, Andi Vajda <va...@apache.org> wrote: > > On Nov 7, 2009, at 2:44, Michael McCandless <luc...@mikemccandless.com> > wrote: > >> Signature & md5 check out. I got everything working and ran my usual >> basic "index & search first 100K docs from wikipedia" smoke test just >> fine. >> >> But a couple questions/issues: >> >> * Is it expected that jcc_ver = '2.4.1' in jcc/setup.py? (Are/were >> we trying to track Lucene's versioning, here? > > No, it's just coincidental. I expect JCC to be at version 2.5 with Lucene > 3.0, for example. As I fixed a few bugs in JCC 2.4 in this release, it > became 2.4.1. OK :) These version numbers are now burned in my mind... >> I wouldn't think >> so, in general, but since that looks like a Lucene version, I'm >> asking...) >> >> * From Makefile, it looks like you're exporting HEAD of Lucene's 2.9 >> branch (instead of the 2.9.1 tag). Is that intended? > > I'm pretty sure I switched to the 2_9_1 tag: > http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_2_9/Makefile Ahh you're right -- I was just confused. Good. >> Also, the >> tar file has Lucene's sources (but in prior releases, I think, you >> let "svn export" retrieve them for me). > > Yes, that's simplifies things in two ways and addresses a user request: > 1. A subversion client is no longer needed to install PyLucene (not there by > default on Windows or Solaris, for example) > 2. By obtaining the Lucene sources along with PyLucene's via a download > mirror, the svn server is getting some welcome relief. Excellent, that makes sense. > You can still get the Lucene sources via the usual svn export by removing > the lucene-java-2.9.1 directory first. > >> >> * I'm using Python 2.6.4 (32 bit), which I downloaded from >> python.org and installed myself. >> >> I hit this: >> >> Traceback (most recent call last): >> File >> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", >> line 122, in _run_module_as_main >> "__main__", fname, loader, pkg_name) >> File >> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", >> line 34, in _run_code >> exec code in run_globals >> File >> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/jcc/__main__.py", >> line 88, in <module> >> cpp.jcc(sys.argv) >> File >> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/jcc/cpp.py", >> line 519, in jcc >> shared, compiler, modules, wininst, arch) >> File >> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/jcc/python.py", >> line 1289, in compile >> raise ImportError, 'setuptools is required when using --shared' >> ImportError: setuptools is required when using --shared > > Yes, setuptools is not distributed with python. If you want to use it you > must install it first. Shared mode depends on it so either you install > setuptools or you don't use --shared Ahh OK. Oh I see, setuptools is bundled with pre-installed Python. >> Removing --shared from Makefile seems to have worked around it. >> I'm assuming this is something silly about my env! > > You can get setuptools from http://python.org/pypi, aka the cheeseshop :) Thanks! Mike
