You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pylucene-dev@lucene.apache.org by Andi Vajda <va...@apache.org> on 2011/12/07 23:50:58 UTC
[VOTE] Release PyLucene 3.5.0 rc2
There were some issues with rc1. Thank you all for having reported them !
Please vote on rc2:
The PyLucene 3.5.0-2 release closely tracking the recent release of
Apache Lucene 3.5.0 is ready.
A release candidate is available from:
http://people.apache.org/~vajda/staging_area/
A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_3_5/CHANGES
PyLucene 3.5.0 is built with JCC 2.12 included in these release artifacts.
A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_5_0/lucene/CHANGES.txt
Please vote to release these artifacts as PyLucene 3.5.0-1.
Thanks !
Andi..
ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS
pps: here is my +1
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
>
> On Thu, 8 Dec 2011, Bill Janssen wrote:
>
> > Andi Vajda <va...@apache.org> wrote:
> >
> >>> Yes, I could see that. setuptools plays all kinds of games to achieve
> >>> its ends, some of them broken. Thank heaven for distutils2/packaging.
> >>
> >> What ? another 'dist' thing ?
> >> So that leaves us with distutils 1, 2, setuptools and distribute. My informa=
> >> tion may be incomplete, out of date or incorrect, of course :-)
> >
> > Yes, after all, an hour has gone by :-).
> >
> > Distutils2 (http://pypi.python.org/pypi/Distutils2) is the Python 2.x
> > name for the new Python 3 packaging system, called, imaginatively
> > enough, "packaging". It replaces "distutils" in Python 3.3. So the
> > "correct" thing to do is to use "distutils2" for Python 2.x-3.2, and
> > "packaging" thereafter; the data files and operation should be the same
> > for both. "setup.py" is gone; long live "setup.cfg". "easy_install" is
> > gone; long live "pysetup run".
>
> What about 'distribute', the python 3.x 'setuptools' replacement that forked
> off of it ?
Obsolete, just like setuptools.
> Can distutils2 build a Library correctly (thus relieving us of setuptools
> requirement for shared mode) ?
It appears to have all the necessary flags and commands for doing so.
Whether or not they work correctly is another question.
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Thu, 8 Dec 2011, Bill Janssen wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>>> Yes, I could see that. setuptools plays all kinds of games to achieve
>>> its ends, some of them broken. Thank heaven for distutils2/packaging.
>>
>> What ? another 'dist' thing ?
>> So that leaves us with distutils 1, 2, setuptools and distribute. My informa=
>> tion may be incomplete, out of date or incorrect, of course :-)
>
> Yes, after all, an hour has gone by :-).
>
> Distutils2 (http://pypi.python.org/pypi/Distutils2) is the Python 2.x
> name for the new Python 3 packaging system, called, imaginatively
> enough, "packaging". It replaces "distutils" in Python 3.3. So the
> "correct" thing to do is to use "distutils2" for Python 2.x-3.2, and
> "packaging" thereafter; the data files and operation should be the same
> for both. "setup.py" is gone; long live "setup.cfg". "easy_install" is
> gone; long live "pysetup run".
What about 'distribute', the python 3.x 'setuptools' replacement that forked
off of it ?
Can distutils2 build a Library correctly (thus relieving us of setuptools
requirement for shared mode) ?
Andi..
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
> > Yes, I could see that. setuptools plays all kinds of games to achieve
> > its ends, some of them broken. Thank heaven for distutils2/packaging.
>
> What ? another 'dist' thing ?
> So that leaves us with distutils 1, 2, setuptools and distribute. My informa=
> tion may be incomplete, out of date or incorrect, of course :-)
Yes, after all, an hour has gone by :-).
Distutils2 (http://pypi.python.org/pypi/Distutils2) is the Python 2.x
name for the new Python 3 packaging system, called, imaginatively
enough, "packaging". It replaces "distutils" in Python 3.3. So the
"correct" thing to do is to use "distutils2" for Python 2.x-3.2, and
"packaging" thereafter; the data files and operation should be the same
for both. "setup.py" is gone; long live "setup.cfg". "easy_install" is
gone; long live "pysetup run".
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Thu, 8 Dec 2011, Andi Vajda wrote:
> It doesn't look like this statement is needed either.
> Can you remember why it was there ? (not saying you put it there, just
> asking, I'm blanking)
>
> Maybe just replacing the whole 'if __name__ ...' block with just:
> from jcc import _jcc
>
> is enough for all cases ?
> (see new version below)
Duh, no more jcc.initVM() then.
Not that it's needed much but for consistency's sake it should probably be
there.
Andi..
>
> Andi..
>
> import os, sys
>
> if sys.platform == 'win32':
>
> if '--find-jvm-dll' in sys.argv:
> from windows import add_jvm_dll_directory_to_path
> add_jvm_dll_directory_to_path()
>
> from jcc.config import SHARED
> if SHARED:
> path = os.environ['Path'].split(os.pathsep)
> eggpath = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
> if eggpath not in path:
> path.insert(0, eggpath)
> os.environ['Path'] = os.pathsep.join(path)
>
> from jcc import _jcc
>
> CLASSPATH=os.path.join(os.path.abspath(os.path.dirname(__file__)),
> "classes")
> _jcc.CLASSPATH = CLASSPATH
>
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Thu, 8 Dec 2011, Andi Vajda wrote:
> It seems that adding, before if __name__ == '__main__':
> from jcc import _jcc
>
> works just fine on 2.7 and 2.6 as well.
>
> Speaking of which, I don't see when __name__ would be == '__main__'. I tried
> various combinations with pdb and __name__ is always == 'jcc'.
> If that makes sense to you as well, I can change that block to just say:
> from _jcc import initVM
It doesn't look like this statement is needed either.
Can you remember why it was there ? (not saying you put it there, just
asking, I'm blanking)
Maybe just replacing the whole 'if __name__ ...' block with just:
from jcc import _jcc
is enough for all cases ?
(see new version below)
Andi..
import os, sys
if sys.platform == 'win32':
if '--find-jvm-dll' in sys.argv:
from windows import add_jvm_dll_directory_to_path
add_jvm_dll_directory_to_path()
from jcc.config import SHARED
if SHARED:
path = os.environ['Path'].split(os.pathsep)
eggpath = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
if eggpath not in path:
path.insert(0, eggpath)
os.environ['Path'] = os.pathsep.join(path)
from jcc import _jcc
CLASSPATH=os.path.join(os.path.abspath(os.path.dirname(__file__)), "classes")
_jcc.CLASSPATH = CLASSPATH
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
> On Thu, 8 Dec 2011, Bill Janssen wrote:
>
> > Andi Vajda <va...@apache.org> wrote:
> >
> >> from _jcc import initVM
> >
> > I believe that in the statement "from X import Y", X and Y are
> > essentially strings, not runtime-evaluated values. So what would
> > work would be
> >
> > from jcc._jcc import initVM
> >
> > or
> >
> > initVM = _jcc.initVM
>
> Thanks for having checked it out.
> I guess we're back to the original with just the _jcc import ahead of
> the block:
>
> ...
> from jcc import _jcc
>
> # used when jcc is invoked with -m from python 2.5
> if __name__ == '__main__':
> import jcc.__main__
> else:
> from _jcc import initVM
> ...
Works in 2.5, anyway.
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Thu, 8 Dec 2011, Bill Janssen wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>> from _jcc import initVM
>
> I believe that in the statement "from X import Y", X and Y are
> essentially strings, not runtime-evaluated values. So what would
> work would be
>
> from jcc._jcc import initVM
>
> or
>
> initVM = _jcc.initVM
Thanks for having checked it out.
I guess we're back to the original with just the _jcc import ahead of the
block:
...
from jcc import _jcc
# used when jcc is invoked with -m from python 2.5
if __name__ == '__main__':
import jcc.__main__
else:
from _jcc import initVM
...
Andi..
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
> from _jcc import initVM
I believe that in the statement "from X import Y", X and Y are
essentially strings, not runtime-evaluated values. So what would
work would be
from jcc._jcc import initVM
or
initVM = _jcc.initVM
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
>
> On Thu, 8 Dec 2011, Bill Janssen wrote:
>
> > Andi Vajda <va...@apache.org> wrote:
> >
> >> It seems that adding, before if __name__ == '__main__':
> >> from jcc import _jcc
> >>
> >> works just fine on 2.7 and 2.6 as well.
> >
> > Yes, this works on 2.5, as well.
> >
> >> Speaking of which, I don't see when __name__ would be == '__main__'. I tried
> >> various combinations with pdb and __name__ is always == 'jcc'.
> >>
> >> If that makes sense to you as well, I can change that block to just say:
> >> from _jcc import initVM
> >
> > I put a print statement in... When you invoke it with Python 2.5 as
> > "python -m jcc", __name__ is "__main__". That's what runs the code,
> > so I don't think you can remove it.
>
> Ah ha. All right, then this change should work:
>
> ...
> # used when jcc is invoked with -m from python 2.5
> if __name__ == '__main__':
> import jcc.__main__
>
> from jcc import _jcc
> from _jcc import initVM
> ...
>
> Andi..
Nope. Here's what I get when I try it:
[...]
creating build/lib.macosx-10.5-i386-2.5
creating build/lib.macosx-10.5-i386-2.5/lucene
g++ -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc build/temp.macosx-10.5-i386-2.5/build/_lucene/__init__.o build/temp.macosx-10.5-i386-2.5/build/_lucene/__wrap01__.o build/temp.macosx-10.5-i386-2.5/build/_lucene/__wrap02__.o build/temp.macosx-10.5-i386-2.5/build/_lucene/__wrap03__.o build/temp.macosx-10.5-i386-2.5/build/_lucene/__wrap04__.o build/temp.macosx-10.5-i386-2.5/build/_lucene/__wrap05__.o build/temp.macosx-10.5-i386-2.5/build/_lucene/functions.o build/temp.macosx-10.5-i386-2.5/build/_lucene/JArray.o build/temp.macosx-10.5-i386-2.5/build/_lucene/JObject.o build/temp.macosx-10.5-i386-2.5/build/_lucene/lucene.o build/temp.macosx-10.5-i386-2.5/build/_lucene/types.o -L/Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg -ljcc -o build/lib.macosx-10.5-i386-2.5/lucene/_lucene.so -framework JavaVM -Wl,-S -Wl,-rpath /Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 95, in run_module
filename, loader, alter_sys)
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 52, in _run_module_code
mod_name, mod_fname, mod_loader)
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 32, in _run_code
exec code in run_globals
File "/Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg/jcc/__init__.py", line 36, in <module>
from _jcc import initVM
ImportError: No module named _jcc
make: *** [compile] Error 255
/tmp/pylucene-3.5.0-2 1142 % cat /Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg/jcc/__init__.py
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# jcc package
import os, sys
if sys.platform == 'win32':
if '--find-jvm-dll' in sys.argv:
from windows import add_jvm_dll_directory_to_path
add_jvm_dll_directory_to_path()
from jcc.config import SHARED
if SHARED:
path = os.environ['Path'].split(os.pathsep)
eggpath = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
if eggpath not in path:
path.insert(0, eggpath)
os.environ['Path'] = os.pathsep.join(path)
# used when jcc is invoked with -m from python 2.5
if __name__ == '__main__':
import jcc.__main__
from jcc import _jcc
from _jcc import initVM
CLASSPATH=os.path.join(os.path.abspath(os.path.dirname(__file__)), "classes")
_jcc.CLASSPATH = CLASSPATH
/tmp/pylucene-3.5.0-2 1143 %
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Thu, 8 Dec 2011, Bill Janssen wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>> It seems that adding, before if __name__ == '__main__':
>> from jcc import _jcc
>>
>> works just fine on 2.7 and 2.6 as well.
>
> Yes, this works on 2.5, as well.
>
>> Speaking of which, I don't see when __name__ would be == '__main__'. I tried
>> various combinations with pdb and __name__ is always == 'jcc'.
>>
>> If that makes sense to you as well, I can change that block to just say:
>> from _jcc import initVM
>
> I put a print statement in... When you invoke it with Python 2.5 as
> "python -m jcc", __name__ is "__main__". That's what runs the code,
> so I don't think you can remove it.
Ah ha. All right, then this change should work:
...
# used when jcc is invoked with -m from python 2.5
if __name__ == '__main__':
import jcc.__main__
from jcc import _jcc
from _jcc import initVM
...
Andi..
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
> It seems that adding, before if __name__ == '__main__':
> from jcc import _jcc
>
> works just fine on 2.7 and 2.6 as well.
Yes, this works on 2.5, as well.
> Speaking of which, I don't see when __name__ would be == '__main__'. I tried
> various combinations with pdb and __name__ is always == 'jcc'.
>
> If that makes sense to you as well, I can change that block to just say:
> from _jcc import initVM
I put a print statement in... When you invoke it with Python 2.5 as
"python -m jcc", __name__ is "__main__". That's what runs the code,
so I don't think you can remove it.
> I'm prepared to roll an rc3 if you confirm that these changes (see
> below) work for you too.
>
> Andi..
>
>
> import os, sys
>
> if sys.platform == 'win32':
>
> if '--find-jvm-dll' in sys.argv:
> from windows import add_jvm_dll_directory_to_path
> add_jvm_dll_directory_to_path()
>
> from jcc.config import SHARED
> if SHARED:
> path = os.environ['Path'].split(os.pathsep)
> eggpath = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
> if eggpath not in path:
> path.insert(0, eggpath)
> os.environ['Path'] = os.pathsep.join(path)
>
> from jcc import _jcc
> from _jcc import initVM
>
> CLASSPATH=os.path.join(os.path.abspath(os.path.dirname(__file__)), "classes")
> _jcc.CLASSPATH = CLASSPATH
No, this doesn't work, but I don't understand the failure...
% /usr/bin/python -m jcc --shared --jar lucene-java-3.5.0/lucene/build/lucene-core-3.5.0.jar --jar lucene-java-3.5.0/lucene/build/contrib/analyzers/common/lucene-analyzers-3.5.0.jar --jar lucene-java-3.5.0/lucene/build/contrib/memory/lucene-memory-3.5.0.jar --jar lucene-java-3.5.0/lucene/build/contrib/highlighter/lucene-highlighter-3.5.0.jar --jar build/jar/extensions.jar --jar lucene-java-3.5.0/lucene/build/contrib/queries/lucene-queries-3.5.0.jar --jar lucene-java-3.5.0/lucene/build/contrib/grouping/lucene-grouping-3.5.0.jar --jar lucene-java-3.5.0/lucene/build/contrib/join/lucene-join-3.5.0.jar --jar lucene-java-3.5.0/lucene/build/contrib/facet/lucene-facet-3.5.0.jar --jar lucene-java-3.5.0/lucene/build/contrib/spellchecker/lucene-spellchecker-3.5.0.jar --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.HashMap java.util.HashSet java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.rege
x --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.QueryParserTokenManager --exclude org.apache.lucene.queryParser.ParseException --exclude org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --exclude org.apache.lucene.analysis.cn.smart.AnalyzerProfile --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 java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' --rename org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer --version 3.5.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --file
s 4 --build
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 95, in run_module
filename, loader, alter_sys)
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 52, in _run_module_code
mod_name, mod_fname, mod_loader)
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 32, in _run_code
exec code in run_globals
File "/Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg/jcc/__init__.py", line 33, in <module>
from _jcc import initVM
ImportError: No module named _jcc
make: *** [compile] Error 255
%
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Thu, 8 Dec 2011, Andi Vajda wrote:
>
> On Dec 8, 2011, at 9:11, Bill Janssen <ja...@parc.com> wrote:
>
>> Andi Vajda <va...@apache.org> wrote:
>>
>>>
>>> On Wed, 7 Dec 2011, Bill Janssen wrote:
>>>
>>>> This part of the PyLucene Makefile is still screwed up:
>>>>
>>>> # Mac OS X 10.5 (32-bit Python 2.5, Java 1.5)
>>>> #PREFIX_PYTHON=/usr
>>>> #ANT=ant
>>>> #PYTHON=$(PREFIX_PYTHON)/bin/python
>>>> #JCC=$(PYTHON) -m jcc --shared
>>>> #NUM_FILES=4
>>>>
>>>> The way that jcc/__init__.py is now written, there's no way to invoke it
>>>> with "-m jcc", even on Python versions where that's supposed to work.
>>>> The last line, "_jcc.CLASSPATH = CLASSPATH" will always fail, because "_jcc"
>>>> isn't imported anywhere.
>>>
>>> I'm a bit confused about how this can or cannot work.
>>> For whatever it's worth, with Python 2.7, running with -m jcc works
>>> fine here.
>>>
>>> That being said, I don't see how this statement:
>>> _jcc.CLASSPATH = CLASSPATH
>>>
>>> can work at all since there is nothing visibly importing _jcc.
>>> Something puts it there, though, because it works.
>>>
>>> Can you shed some light on this ?
>>>
>>> ... debugging a bit further ... via pdb ...
>>>
>>> Apparently, the statement:
>>> from _jcc import initVM
>>>
>>> causes the _jcc symbol to appear.
>>
>> That seems broken. Certainly shouldn't work that way.
>>
>>> This could be a side-effect of setuptools. I vaguely remember someone
>>> saying that this didn't work with distutils only.
>>
>> Yes, I could see that. setuptools plays all kinds of games to achieve
>> its ends, some of them broken. Thank heaven for distutils2/packaging.
>
> What ? another 'dist' thing ?
> So that leaves us with distutils 1, 2, setuptools and distribute. My information may be incomplete, out of date or incorrect, of course :-)
>
>>> If you can reproduce the failure, does adding a line before if __name__ ...:
>>> import _jcc
>>>
>>> solve the problem for you ?
>>
>> No, I get an import error there -- apparently the relative import isn't
>> seen/found:
>>
>> Traceback (most recent call last):
>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 95, in run_module
>> filename, loader, alter_sys)
>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 52, in _run_module_code
>> mod_name, mod_fname, mod_loader)
>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 32, in _run_code
>> exec code in run_globals
>> File "/Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg/jcc/__init__.py", line 31, in <module>
>> import _jcc
>> ImportError: No module named _jcc
>> make: *** [compile] Error 255
>>
>>
>> But using
>>
>> import jcc._jcc
>>
>> does work. Wonder if that works on Python 2.7, too?
>
> Let me give this a try....
It seems that adding, before if __name__ == '__main__':
from jcc import _jcc
works just fine on 2.7 and 2.6 as well.
Speaking of which, I don't see when __name__ would be == '__main__'. I tried
various combinations with pdb and __name__ is always == 'jcc'.
If that makes sense to you as well, I can change that block to just say:
from _jcc import initVM
I'm prepared to roll an rc3 if you confirm that these changes (see
below) work for you too.
Andi..
import os, sys
if sys.platform == 'win32':
if '--find-jvm-dll' in sys.argv:
from windows import add_jvm_dll_directory_to_path
add_jvm_dll_directory_to_path()
from jcc.config import SHARED
if SHARED:
path = os.environ['Path'].split(os.pathsep)
eggpath = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
if eggpath not in path:
path.insert(0, eggpath)
os.environ['Path'] = os.pathsep.join(path)
from jcc import _jcc
from _jcc import initVM
CLASSPATH=os.path.join(os.path.abspath(os.path.dirname(__file__)), "classes")
_jcc.CLASSPATH = CLASSPATH
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Dec 8, 2011, at 9:11, Bill Janssen <ja...@parc.com> wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>>
>> On Wed, 7 Dec 2011, Bill Janssen wrote:
>>
>>> This part of the PyLucene Makefile is still screwed up:
>>>
>>> # Mac OS X 10.5 (32-bit Python 2.5, Java 1.5)
>>> #PREFIX_PYTHON=/usr
>>> #ANT=ant
>>> #PYTHON=$(PREFIX_PYTHON)/bin/python
>>> #JCC=$(PYTHON) -m jcc --shared
>>> #NUM_FILES=4
>>>
>>> The way that jcc/__init__.py is now written, there's no way to invoke it
>>> with "-m jcc", even on Python versions where that's supposed to work.
>>> The last line, "_jcc.CLASSPATH = CLASSPATH" will always fail, because "_jcc"
>>> isn't imported anywhere.
>>
>> I'm a bit confused about how this can or cannot work.
>> For whatever it's worth, with Python 2.7, running with -m jcc works
>> fine here.
>>
>> That being said, I don't see how this statement:
>> _jcc.CLASSPATH = CLASSPATH
>>
>> can work at all since there is nothing visibly importing _jcc.
>> Something puts it there, though, because it works.
>>
>> Can you shed some light on this ?
>>
>> ... debugging a bit further ... via pdb ...
>>
>> Apparently, the statement:
>> from _jcc import initVM
>>
>> causes the _jcc symbol to appear.
>
> That seems broken. Certainly shouldn't work that way.
>
>> This could be a side-effect of setuptools. I vaguely remember someone
>> saying that this didn't work with distutils only.
>
> Yes, I could see that. setuptools plays all kinds of games to achieve
> its ends, some of them broken. Thank heaven for distutils2/packaging.
What ? another 'dist' thing ?
So that leaves us with distutils 1, 2, setuptools and distribute. My information may be incomplete, out of date or incorrect, of course :-)
>> If you can reproduce the failure, does adding a line before if __name__ ...:
>> import _jcc
>>
>> solve the problem for you ?
>
> No, I get an import error there -- apparently the relative import isn't
> seen/found:
>
> Traceback (most recent call last):
> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 95, in run_module
> filename, loader, alter_sys)
> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 52, in _run_module_code
> mod_name, mod_fname, mod_loader)
> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 32, in _run_code
> exec code in run_globals
> File "/Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg/jcc/__init__.py", line 31, in <module>
> import _jcc
> ImportError: No module named _jcc
> make: *** [compile] Error 255
>
>
> But using
>
> import jcc._jcc
>
> does work. Wonder if that works on Python 2.7, too?
Let me give this a try....
Andi..
>
> Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
>
> On Wed, 7 Dec 2011, Bill Janssen wrote:
>
> > This part of the PyLucene Makefile is still screwed up:
> >
> > # Mac OS X 10.5 (32-bit Python 2.5, Java 1.5)
> > #PREFIX_PYTHON=/usr
> > #ANT=ant
> > #PYTHON=$(PREFIX_PYTHON)/bin/python
> > #JCC=$(PYTHON) -m jcc --shared
> > #NUM_FILES=4
> >
> > The way that jcc/__init__.py is now written, there's no way to invoke it
> > with "-m jcc", even on Python versions where that's supposed to work.
> > The last line, "_jcc.CLASSPATH = CLASSPATH" will always fail, because "_jcc"
> > isn't imported anywhere.
>
> I'm a bit confused about how this can or cannot work.
> For whatever it's worth, with Python 2.7, running with -m jcc works
> fine here.
>
> That being said, I don't see how this statement:
> _jcc.CLASSPATH = CLASSPATH
>
> can work at all since there is nothing visibly importing _jcc.
> Something puts it there, though, because it works.
>
> Can you shed some light on this ?
>
> ... debugging a bit further ... via pdb ...
>
> Apparently, the statement:
> from _jcc import initVM
>
> causes the _jcc symbol to appear.
That seems broken. Certainly shouldn't work that way.
> This could be a side-effect of setuptools. I vaguely remember someone
> saying that this didn't work with distutils only.
Yes, I could see that. setuptools plays all kinds of games to achieve
its ends, some of them broken. Thank heaven for distutils2/packaging.
> If you can reproduce the failure, does adding a line before if __name__ ...:
> import _jcc
>
> solve the problem for you ?
No, I get an import error there -- apparently the relative import isn't
seen/found:
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 95, in run_module
filename, loader, alter_sys)
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 52, in _run_module_code
mod_name, mod_fname, mod_loader)
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/runpy.py", line 32, in _run_code
exec code in run_globals
File "/Library/Python/2.5/site-packages/JCC-2.12-py2.5-macosx-10.5-i386.egg/jcc/__init__.py", line 31, in <module>
import _jcc
ImportError: No module named _jcc
make: *** [compile] Error 255
But using
import jcc._jcc
does work. Wonder if that works on Python 2.7, too?
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Wed, 7 Dec 2011, Bill Janssen wrote:
> This part of the PyLucene Makefile is still screwed up:
>
> # Mac OS X 10.5 (32-bit Python 2.5, Java 1.5)
> #PREFIX_PYTHON=/usr
> #ANT=ant
> #PYTHON=$(PREFIX_PYTHON)/bin/python
> #JCC=$(PYTHON) -m jcc --shared
> #NUM_FILES=4
>
> The way that jcc/__init__.py is now written, there's no way to invoke it
> with "-m jcc", even on Python versions where that's supposed to work.
> The last line, "_jcc.CLASSPATH = CLASSPATH" will always fail, because "_jcc"
> isn't imported anywhere.
I'm a bit confused about how this can or cannot work.
For whatever it's worth, with Python 2.7, running with -m jcc works fine
here.
That being said, I don't see how this statement:
_jcc.CLASSPATH = CLASSPATH
can work at all since there is nothing visibly importing _jcc.
Something puts it there, though, because it works.
Can you shed some light on this ?
... debugging a bit further ... via pdb ...
Apparently, the statement:
from _jcc import initVM
causes the _jcc symbol to appear.
This could be a side-effect of setuptools. I vaguely remember someone saying
that this didn't work with distutils only.
If you can reproduce the failure, does adding a line before if __name__ ...:
import _jcc
solve the problem for you ?
Andi..
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
This part of the PyLucene Makefile is still screwed up:
# Mac OS X 10.5 (32-bit Python 2.5, Java 1.5)
#PREFIX_PYTHON=/usr
#ANT=ant
#PYTHON=$(PREFIX_PYTHON)/bin/python
#JCC=$(PYTHON) -m jcc --shared
#NUM_FILES=4
The way that jcc/__init__.py is now written, there's no way to invoke it
with "-m jcc", even on Python versions where that's supposed to work.
The last line, "_jcc.CLASSPATH = CLASSPATH" will always fail, because "_jcc"
isn't imported anywhere.
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
My Leopard machine is happy with this one. "make test" works, and my code
seems to work with it, as well.
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Andi Vajda <va...@apache.org>.
On Dec 7, 2011, at 17:15, Bill Janssen <ja...@parc.com> wrote:
> My Windows machine is mentioning "ICU not installed".
Not a problem.
> Shouldn't the Makefile conditionalize the wrapping of
> ICUNormalizer2Filter.py, ICUFoldingFilter.py, and ICUTransformFilter.py
> on that?
Not sure what you mean here by wrapping of these python files but the corresponding ImportError in them is taken care of.
Andi..
>
> Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
My Windows machine is mentioning "ICU not installed".
Shouldn't the Makefile conditionalize the wrapping of
ICUNormalizer2Filter.py, ICUFoldingFilter.py, and ICUTransformFilter.py
on that?
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
This part of the PyLucene Makefile is still screwed up:
# Mac OS X 10.5 (32-bit Python 2.5, Java 1.5)
#PREFIX_PYTHON=/usr
#ANT=ant
#PYTHON=$(PREFIX_PYTHON)/bin/python
#JCC=$(PYTHON) -m jcc --shared
#NUM_FILES=4
The way that jcc/__init__.py is now written, there's no way to invoke it
with "-m jcc", even on Python versions where that's supposed to work.
The last line, "_jcc.CLASSPATH = CLASSPATH" will always fail, because "_jcc"
isn't imported anywhere.
Bill
Re: [VOTE] Release PyLucene 3.5.0 rc2
Posted by Bill Janssen <ja...@parc.com>.
My Windows machine is mentioning "ICU not installed".
Shouldn't the Makefile conditionalize the wrapping of
ICUNormalizer2Filter.py, ICUFoldingFilter.py, and ICUTransformFilter.py
on that?
Bill