On Dec 7, 2011, at 17:15, Bill Janssen <[EMAIL PROTECTED]> 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

+1 to release.

I ran my usual smoke test: indexing and searching first 100K Wikipedia
docs, OS X 10.6.8, Java 1.6.0_22, Python 2.6.1.

Mike McCandless

http://blog.mikemccandless.com

On Fri, Dec 9, 2011 at 12:26 AM, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> There were some issues again with rc2.
> Thank you all for having reported them !
>
> Please vote on rc3:
>
> The PyLucene 3.5.0-3 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-3.
>
> 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

Am 09.12.2011 06:26, schrieb Andi Vajda:
>
> There were some issues again with rc2.
> Thank you all for having reported them !
>
> Please vote on rc3:
>
> The PyLucene 3.5.0-3 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-3.

+1 from me

JCC 2.12 and PyLucene 3.5.0-3 compiles and works with Python 2.7 and JRE
1.6.0_29 on X64_86 Ubuntu. All tests of our application pass and our
bobo-browse integration works.

Christian

Just built on XP with MinGW, Python 2.6, and "make test" seems to work fine.

Bill

> A release candidate is available from:
> http://people.apache.org/~vajda/staging_area/

Works on my OS X 10.5 machine.

Bill

My Leopard machine is happy with this one.  "make test" works, and my code
seems to work with it, as well.

Bill

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..

Andi Vajda <[EMAIL PROTECTED]> 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

On Dec 8, 2011, at 9:11, Bill Janssen <[EMAIL PROTECTED]> wrote:

> Andi Vajda <[EMAIL PROTECTED]> 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

On Thu, 8 Dec 2011, Andi Vajda wrote:

>
> On Dec 8, 2011, at 9:11, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
>> Andi Vajda <[EMAIL PROTECTED]> 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

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

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
>

Andi Vajda <[EMAIL PROTECTED]> 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

On Thu, 8 Dec 2011, Bill Janssen wrote:

> Andi Vajda <[EMAIL PROTECTED]> 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..

Andi Vajda <[EMAIL PROTECTED]> wrote:

>
> On Thu, 8 Dec 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> 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 %

Andi Vajda <[EMAIL PROTECTED]> 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

On Thu, 8 Dec 2011, Bill Janssen wrote:

> Andi Vajda <[EMAIL PROTECTED]> 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..

Andi Vajda <[EMAIL PROTECTED]> wrote:

> On Thu, 8 Dec 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> 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

Andi Vajda <[EMAIL PROTECTED]> 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

On Thu, 8 Dec 2011, Bill Janssen wrote:

> Andi Vajda <[EMAIL PROTECTED]> 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..

Andi Vajda <[EMAIL PROTECTED]> wrote:

>
> On Thu, 8 Dec 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> 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