On Sat, 7 Nov 2009, Michael McCandless wrote:
OK thanks Andi, +1 to release! (minor comments below)
Thanks Mike !
Here is my +1 as well.
We now have 2 votes approving these release artifacts.
One more is needed...
Andi..
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
