[jira] [Resolved] (PYLUCENE-70) JCC --generate missing additional \ on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-70.

Resolution: Fixed

fixed in rev 1916468.

> JCC --generate missing additional \ on windows
> --
>
> Key: PYLUCENE-70
> URL: https://issues.apache.org/jira/browse/PYLUCENE-70
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows11, conda python package
>Reporter: Petrus Hyvönen
>Priority: Blocker
> Attachments: issue_escape_package_dir.patch, jcc_python.patch
>
>
> The --generate seems to be missing double 
> in package_dir parameter on windows platform
> In tests at JCC conda build feedstock 
> ([https://github.com/conda-forge/jcc-feedstock/tree/main/recipe/test/java-example-test-parameters])
> --generates gives a setup.py with row:
> 
>package_dir={"test1": "build\test1"},
>  
> But should be:
>   package_dir={"test1": "build\\test1"},



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-70) JCC --generate missing additional \ on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827781#comment-17827781
 ] 

Andi Vajda commented on PYLUCENE-70:


Hi Petrus, thank you for the bug report and patch.
Please, test the attached jcc_python.patch file that handles more than just 
package_dir and switches to using r"strings" where \ chars are not a problem.
I don't have access to Windows, your help in verifying this patch is 
appreciated !

> JCC --generate missing additional \ on windows
> --
>
> Key: PYLUCENE-70
> URL: https://issues.apache.org/jira/browse/PYLUCENE-70
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows11, conda python package
>Reporter: Petrus Hyvönen
>Priority: Blocker
> Attachments: issue_escape_package_dir.patch, jcc_python.patch
>
>
> The --generate seems to be missing double 
> in package_dir parameter on windows platform
> In tests at JCC conda build feedstock 
> ([https://github.com/conda-forge/jcc-feedstock/tree/main/recipe/test/java-example-test-parameters])
> --generates gives a setup.py with row:
> 
>package_dir={"test1": "build\test1"},
>  
> But should be:
>   package_dir={"test1": "build\\test1"},



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (PYLUCENE-70) JCC --generate missing additional \ on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda updated PYLUCENE-70:
---
Attachment: jcc_python.patch

> JCC --generate missing additional \ on windows
> --
>
> Key: PYLUCENE-70
> URL: https://issues.apache.org/jira/browse/PYLUCENE-70
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows11, conda python package
>Reporter: Petrus Hyvönen
>Priority: Blocker
> Attachments: issue_escape_package_dir.patch, jcc_python.patch
>
>
> The --generate seems to be missing double 
> in package_dir parameter on windows platform
> In tests at JCC conda build feedstock 
> ([https://github.com/conda-forge/jcc-feedstock/tree/main/recipe/test/java-example-test-parameters])
> --generates gives a setup.py with row:
> 
>package_dir={"test1": "build\test1"},
>  
> But should be:
>   package_dir={"test1": "build\\test1"},



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release PyLucene 9.10.0-rc1

[Andi Vajda]

Thank you all who voted.
Thank you Dawid and Mike for your PMC +1 votes as well.

This vote has passed !
Expect a release shortly...

Andi..

On Wed, 21 Feb 2024, Andi Vajda wrote:


The PyLucene 9.10.0 (rc1) release tracking the recent release of
Apache Lucene 9.10.0 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.10.0-rc1/

PyLucene 9.10.0 is built with JCC 3.14, included in these release artifacts.

Apart from the catch-up to Lucene 9.10.0, the other major new feature in this 
release candidate is that JCC can now generate a setup.py file instead of 
calling Setup() directly. This makes it possible to use modern Python 
packaging without falling afoul of "python setup.py install" being
deprecated. Setup.py itself is not deprecated, only some of its associated 
commands are; see [1] for more information about this.


In PyLucene's Makefile, there now is a new MODERN_PACKAGING variable, which 
can be set to true so that "python -m build" and "python -m pip install" are 
used for building and installing PyLucene.


JCC 3.14 supports Python 3.3 up to Python 3.12.
PyLucene may also be built with Python 2 but this configuration is no longer
tested.

Please vote to release these artifacts as PyLucene 9.10.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[1] https://packaging.python.org/en/latest/discussions/setup-py-deprecated/

Re: The future of the PyLucene project

[Andi Vajda]

So it does look like there are users of PyLucene who would like the project 
to continue, after all. As long as there is interest I'm happy to continue 
with it as well.


Thank you all who responded to this thread !

Andi..

On Wed, 28 Feb 2024, Andi Vajda wrote:



Hi PyLucene users and Lucene PMC,

A week ago, on Wednesday February 21st, I started a voting thread for 
qualifying a new PyLucene release candidate to catch-up with the recent 
Lucene 9.10.0 release and fix a bug in JCC.


Usually these voting threads get a couple of +1 for PyLucene users before 
getting votes from a couple of people on the Lucene PMC, always the same ones 
;-) Three PMC +1 votes -> a release can happen.


This time, crickets, the voting thread has been completely quiet.

If there are no PyLucene users anymore, maybe it's time to shut the project 
down ? Personally, I think that the "software value" in the project is all in 
JCC. PyLucene itself is 99% machine generated by JCC around Java Lucene.


Of course, having Java Lucene available that way from Python is pretty cool 
so I don't want diminish PyLucene's "usage value", but from a software 
engineering standpoint, the itch, if you prefer, all the cool stuff is done 
in JCC.


If the Lucene PMC agrees and no PyLucene users come forward, I propose the 
following:

 - shutdown the PyLucene project
 - fork JCC to my gitlab (https://gitlab.pyicu.org/main) where it can
   get the occasional fix or improvement before being released to PyPI.
   JCC has been distributed from PyPI forever,
 https://pypi.org/project/JCC/#history
   so JCC users shouldn't even notice this...

What do you all think ?
This message is not a vote, I'm just trying to gauge interest in PyLucene and 
JCC.


Andi..

ps: for those who have never heard of PyLucene, it is a sub-project of
   Apache Lucene hosted here:
 https://lucene.apache.org/pylucene/index.html
pps: for those who have never heard of JCC, it is a sub-project of PyLucene
 hosted here: https://lucene.apache.org/pylucene/jcc/index.html

Re: The future of the PyLucene project

[Andi Vajda]

On Wed, 28 Feb 2024, Erik Groeneveld LPV wrote:

I always followed new releases and checked the change log for both 
PyLucene and Lucene. I never felt entitled to vote however.


This seems to be a common misconception.
Everyone can vote on a release, everyone is entitled to.
It's just an Apache Rule that 3 PMC +1 votes are required to make a release.

Look at it this way: if a non-PMC user votes +1, it's a sign of interest.
If such a user votes -1, it's even more: a sign of participation and a 
non-binding veto to the release.
Sure, according to the rules, one can ignore it and go ahead with the 
release but what does that say to your user community ?


Of course anyone can vote !
Anyone interested in this project can and should vote !
If no one does, how do we know anyone cares ?

Andi..



I can still vote, but I think it would be more appropriate if Thijs does 
that.


Keep up the good work!
Erik

On Wed, Feb 28, 2024 at 21:08, Dawid Weiss <[dawid.we...@gmail.com](mailto:On Wed, Feb 
28, 2024 at 21:08, Dawid Weiss < wrote:


Hi Andi,

This time, crickets, the voting thread has been completely quiet.




For me - and it's not an excuse at all - you hit winter holidays, I'm
really sorry!


If the Lucene PMC agrees and no PyLucene users come forward, I propose the
following:
- shutdown the PyLucene project
- fork JCC to my gitlab (https://gitlab.pyicu.org/main) where it can
get the occasional fix or improvement before being released to PyPI.
JCC has been distributed from PyPI forever,
https://pypi.org/project/JCC/#history
so JCC users shouldn't even notice this...



I think open source is mostly about the community and folks coding together
for fun... And not many of us seem to be
able to help you with PyLucene development - I can't, for that matter,
because my Python is really limited.

Your plan sounds good to me. And you'd get more freedom from procedural
release
requirements at Apache too, which sounds like an added benefit?... :)

I also hope that, regardless of the status of PyLucene and JCC, you remain
with the Lucene project.

Dawid

--
Seecr is een kleine groep zeer ervaren full cycle software engineers. We
specialiseren ons in Linux, search en dataverwerking met de laatste
technieken. Wilt u weten meer weten? Kijk op seecr.nl .

The future of the PyLucene project

[Andi Vajda]

 Hi PyLucene users and Lucene PMC,

A week ago, on Wednesday February 21st, I started a voting thread for 
qualifying a new PyLucene release candidate to catch-up with the recent 
Lucene 9.10.0 release and fix a bug in JCC.


Usually these voting threads get a couple of +1 for PyLucene users before 
getting votes from a couple of people on the Lucene PMC, always the same 
ones ;-) Three PMC +1 votes -> a release can happen.


This time, crickets, the voting thread has been completely quiet.

If there are no PyLucene users anymore, maybe it's time to shut the project 
down ? Personally, I think that the "software value" in the project is all 
in JCC. PyLucene itself is 99% machine generated by JCC around Java Lucene.


Of course, having Java Lucene available that way from Python is pretty cool 
so I don't want diminish PyLucene's "usage value", but from a software 
engineering standpoint, the itch, if you prefer, all the cool stuff is done 
in JCC.


If the Lucene PMC agrees and no PyLucene users come forward, I propose the 
following:

  - shutdown the PyLucene project
  - fork JCC to my gitlab (https://gitlab.pyicu.org/main) where it can
get the occasional fix or improvement before being released to PyPI.
JCC has been distributed from PyPI forever,
  https://pypi.org/project/JCC/#history
so JCC users shouldn't even notice this...

What do you all think ?
This message is not a vote, I'm just trying to gauge interest in PyLucene 
and JCC.


Andi..

ps: for those who have never heard of PyLucene, it is a sub-project of
Apache Lucene hosted here:
  https://lucene.apache.org/pylucene/index.html
pps: for those who have never heard of JCC, it is a sub-project of PyLucene
  hosted here: https://lucene.apache.org/pylucene/jcc/index.html

[VOTE] Release PyLucene 9.10.0-rc1

[Andi Vajda]

The PyLucene 9.10.0 (rc1) release tracking the recent release of
Apache Lucene 9.10.0 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.10.0-rc1/

PyLucene 9.10.0 is built with JCC 3.14, included in these release artifacts.

Apart from the catch-up to Lucene 9.10.0, the other major new feature in 
this release candidate is that JCC can now generate a setup.py file instead 
of calling Setup() directly. This makes it possible to use modern Python 
packaging without falling afoul of "python setup.py install" being
deprecated. Setup.py itself is not deprecated, only some of its associated 
commands are; see [1] for more information about this.


In PyLucene's Makefile, there now is a new MODERN_PACKAGING variable, which 
can be set to true so that "python -m build" and "python -m pip install" are 
used for building and installing PyLucene.


JCC 3.14 supports Python 3.3 up to Python 3.12.
PyLucene may also be built with Python 2 but this configuration is no longer
tested.

Please vote to release these artifacts as PyLucene 9.10.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[1] https://packaging.python.org/en/latest/discussions/setup-py-deprecated/

[jira] [Commented] (PYLUCENE-65) Support the default java on debian in `setup.py`.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815420#comment-17815420
 ] 

Andi Vajda commented on PYLUCENE-65:


on my rather old debian install and also on ubuntu 22.04, I get these packages 
when I search for default-java

apt search default-java
Sorting... Done
Full Text Search... Done
libplexus-container-default-java/jammy 2.1.0-1 all
  Plexus Inversion-of-control Container

libplexus-container-default1.5-java/jammy 2.1.0-1 all
  Plexus Inversion-of-control Container (transitional package)

which java are you referring to ?
Does the fix you propose apply only to Debian and its derivatives ?

> Support the default java on debian in `setup.py`.
> -
>
> Key: PYLUCENE-65
> URL: https://issues.apache.org/jira/browse/PYLUCENE-65
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: A. Coady
>Priority: Major
>
> On debian, the `default-java` package does not have `jre/lib/amd64` in its 
> path, so it breaks the `linux/x86_64` build. The `temurin` flags have the 
> correct paths, so one easy fix would be to change the [temurin 
> check|https://svn.apache.org/viewvc/lucene/pylucene/trunk/jcc/setup.py?revision=1900087=markup#l194]
>  to:
> {code:python}
>     if 'temurin' in JDK['linux'] or 'default' in JDK['linux']:
> {code}
> That would also support `linux/aarch64` without any further changes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-69) Linking libjvm seems to prevent PyPi upload

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815416#comment-17815416
 ] 

Andi Vajda commented on PYLUCENE-69:


Try with the latest but I doubt you'll be able to build a wheel that includes 
the JVM.

> Linking libjvm seems to prevent PyPi upload
> ---
>
> Key: PYLUCENE-69
> URL: https://issues.apache.org/jira/browse/PYLUCENE-69
> Project: PyLucene
>  Issue Type: Question
>Reporter: Clément Jonglez
>Priority: Major
>
> As mentioned in 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] , I am 
> trying to package the Orekit Python wrapper from [~petrush] (which uses JCC) 
> to PyPi.
> I used the --wheel option to compile a wheel and not an egg, and I tried to 
> upload the wheel to PyPi.
> But PyPi refuses my wheel with the answer :
> {noformat}
> Binary wheel 'orekit-11.3.3-cp312-cp312-linux_x86_64.whl' has an unsupported 
> platform tag 'linux_x86_64'. {noformat}
> After reading about why this error occurs ( 
> [https://peps.python.org/pep-0513/#rationale] )  , I tried to convert the 
> wheel to a manylinux wheel by using:
>  
> {code:java}
> auditwheel repair dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned the following error:
>  
> {noformat}
> auditwheel: error: cannot repair 
> "dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl" to "manylinux_2_5_x86_64" 
> ABI because of the presence of too-recent versioned symbols. You'll need to 
> compile the wheel on an older toolchain.{noformat}
>  
> I then ran the following command to get more information about which symbols 
> are problematic in the wheel:
>  
> {code:java}
> auditwheel-symbols --manylinux 2_34 
> dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned:
>  
> {noformat}
> orekit/_orekit.cpython-312-x86_64-linux-gnu.so is not manylinux_2_34 
> compliant because it links the following forbidden libraries:
> libjvm.so{noformat}
>  
>  
> I tried removing -ljvm from the LFLAGS list in jcc's config.py, but as 
> expected the Python program then fails on starting the JVM:
> {noformat}
> Traceback (most recent call last):
>   File "/media/ssd/git/orekit_python_artifacts/test/AbstractDetectorTest.py", 
> line 3, in 
>     import orekit
>   File 
> "/home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/__init__.py",
>  line 7, in 
>     from . import _orekit
> ImportError: 
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/_orekit.cpython-312-x86_64-linux-gnu.so:
>  undefined symbol: JNI_GetDefaultJavaVMInitArgs{noformat}
>  
> I don't have any more clues... Alternatively, I could try to package the 
> Orekit Python wrapper as a source distribution (using 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-27] and 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] ), but 
> this would mean that a user would need to wait approx. 10 minutes for the 
> wheel to compile when running pip install...
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-68.

Resolution: Fixed

Fixed in HEAD.

> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://github.com/pypa/setuptools/issues/917 for details.
>         
> 
> !!
>   self.initialize_options()
>  
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815414#comment-17815414
 ] 

Andi Vajda edited comment on PYLUCENE-68 at 2/7/24 7:51 PM:


I looked into this issue a bit more now and setup.py is _not_ deprecated, see 
this 
[doc|https://packaging.python.org/en/latest/discussions/setup-py-deprecated/] 
for more about this topic.
What is deprecated are _some_ of the commands usually passed to setup.py, such 
as install, which JCC uses, in some cases, when it invokes setup() directly (at 
the bottom of python.py).
I fixed this now by adding support for a new --generate flag that supercedes 
--build and other such flags and, instead of calling setup() JCC produces a 
setup.py file for the extension. This setup.py file can then be used with 
modern python packaging tools such as build and pip.
The pylucene build is being switched to this and the process to build PyLucene 
is then:
  - build and install jcc using the modern tools:
  - python -m build
  - python -m pip install --force

  - build pylucene:
  - set MODERN_PACKAGING to true in Makefile
  - make all
 which runs:
  - jcc is invoked with --generate
  - python -m build -nw
  - python -m pip install --force



was (Author: vajda):
I looked into this issue a bit more now and setup.py is _not_ deprecated, see 
this 
[doc|https://packaging.python.org/en/latest/discussions/setup-py-deprecated/] 
for more about this topic.
What is deprecated are _some_ of the commands usually passed to setup.py, such 
as install, which JCC uses, in some cases, when it invokes setup() directly (at 
the bottom of python.py).
I fixed this now by adding support for a new --generate flag that supercedes 
--build and other such flags and, instead of calling setup() JCC produces a 
setup.py file for the extension. This setup.py file can then be used with 
modern python packaging tools such as build and pip.
The pylucene build is being switched to this and the process to build PyLucene 
is then:
  - build and install jcc using the modern tools:
  - python -m build
  - python -m pip install --force
  - build pylucene:
  - set MODERN_PACKAGING to true in Makefile
  - make all
 which runs:
  - jcc is invoked with --generate
  - python -m build -nw
  - python -m pip install --force


> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>      

[jira] [Commented] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815414#comment-17815414
 ] 

Andi Vajda commented on PYLUCENE-68:


I looked into this issue a bit more now and setup.py is _not_ deprecated, see 
this 
[doc|https://packaging.python.org/en/latest/discussions/setup-py-deprecated/] 
for more about this topic.
What is deprecated are _some_ of the commands usually passed to setup.py, such 
as install, which JCC uses, in some cases, when it invokes setup() directly (at 
the bottom of python.py).
I fixed this now by adding support for a new --generate flag that supercedes 
--build and other such flags and, instead of calling setup() JCC produces a 
setup.py file for the extension. This setup.py file can then be used with 
modern python packaging tools such as build and pip.
The pylucene build is being switched to this and the process to build PyLucene 
is then:
  - build and install jcc using the modern tools:
  - python -m build
  - python -m pip install --force
  - build pylucene:
  - set MODERN_PACKAGING to true in Makefile
  - make all
 which runs:
  - jcc is invoked with --generate
  - python -m build -nw
  - python -m pip install --force


> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://github.com/pypa/setuptools/issues/917 for details.
>         
> 
> !!
>   self.initialize_options()
>  
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Fwd: Where to report issues with lucene/pylucene

[Andi Vajda]

Begin forwarded message:

> From: Andi Vajda 
> Date: January 8, 2024 at 15:59:29 GMT+1
> To: d...@lucene.apache.org
> Subject: Re: Where to report issues with lucene/pylucene
> Reply-To: d...@lucene.apache.org
> 
> 
>> On Sun, 7 Jan 2024, Bob Kline wrote:
>> 
>> On Sun, Jan 7, 2024 at 7:10 AM Bob Kline  wrote:
>> 
>> I figured out how to get past all the problems I ran into, and was finally
>> able to get the package built and installed. Afterwards I captured notes on
>> the process so if I (or a colleague) needs to do this again, we'll have a
>> head start. I'm sharing these notes (attached) in case any of the
>> information might suggest improvements to the instructions page
>> <https://lucene.apache.org/pylucene/install.html>. Feel free to use or
>> ignore any of these notes as you think appropriate.
> 
> Thank you for your notes. Replies inline:
> 
>> Skip over the "For the Impatient Ones" section. Those steps won't work
>> because the Makefile must be edited first.
> 
> Well, the steps said to edit setup.py and Makefile to match your environment 
> except that the markup on the site was bogus for those lines and these 
> instructions were not rendered :-(
> I fixed that now: https://lucene.apache.org/pylucene/install.html
> 
>> The build will not be able to use the Ubuntu distro's jcc, because it's
>> not built to support the --shared option.
> 
> I wasn't aware that Ubuntu has a prebuilt package for JCC now. If it is not 
> built with --shared then you can't use shared mode for PyLucene. If all you 
> need/want is build PyLucene and no other wrappers later around other JARs for 
> use in the same VM, then you can skip shared mode and drop --shared from the 
> JCC invocations.
> 
>> The makefile needs help finding the JDK libraries.
> 
> This shouldn't be necessary as JCC, when setup.py is edited as required, will 
> populate that information.
> 
>> sudo make test
> 
> I would stronly recommend using a python virtual environment (venv) so that 
> you don't pollute the system python with your work. This doesn't require root 
> nor later careful cleanup of the system python installation should something 
> go wrong. Yes, 20 years ago, when PyLucene/JCC were started, venv wasn't as 
> much of a thing but nowadays it's very good practice.
> 
>> All of the tests pass except one:
> 
> I wonder what version of PyICU you have installed. I just verified that tests 
> do all pass if you do _not_ have PyICU installed.
> 
> Andi..
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Where to report issues with lucene/pylucene

[Andi Vajda]

On Sun, 7 Jan 2024, Bob Kline wrote:


On Sun, Jan 7, 2024 at 7:10 AM Bob Kline  wrote:

I figured out how to get past all the problems I ran into, and was finally
able to get the package built and installed. Afterwards I captured notes on
the process so if I (or a colleague) needs to do this again, we'll have a
head start. I'm sharing these notes (attached) in case any of the
information might suggest improvements to the instructions page
. Feel free to use or
ignore any of these notes as you think appropriate.


Thank you for your notes. Replies inline:


Skip over the "For the Impatient Ones" section. Those steps won't work
because the Makefile must be edited first.


Well, the steps said to edit setup.py and Makefile to match your environment 
except that the markup on the site was bogus for those lines and these 
instructions were not rendered :-(

I fixed that now: https://lucene.apache.org/pylucene/install.html


The build will not be able to use the Ubuntu distro's jcc, because it's
not built to support the --shared option.


I wasn't aware that Ubuntu has a prebuilt package for JCC now. If it is not 
built with --shared then you can't use shared mode for PyLucene. If all you 
need/want is build PyLucene and no other wrappers later around other JARs 
for use in the same VM, then you can skip shared mode and drop --shared 
from the JCC invocations.



The makefile needs help finding the JDK libraries.


This shouldn't be necessary as JCC, when setup.py is edited as required, 
will populate that information.



sudo make test


I would stronly recommend using a python virtual environment (venv) so that 
you don't pollute the system python with your work. This doesn't require 
root nor later careful cleanup of the system python installation should 
something go wrong. Yes, 20 years ago, when PyLucene/JCC were started, venv 
wasn't as much of a thing but nowadays it's very good practice.



All of the tests pass except one:


I wonder what version of PyICU you have installed. I just verified that 
tests do all pass if you do _not_ have PyICU installed.


Andi..

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Where to report issues with lucene/pylucene

[Andi Vajda]

On Jan 7, 2024, at 15:57, Bob Kline  wrote:I tried to sign up with ASF's JIRA system but got the messageThe project you have selected does not use Jira for issue tracking. Please contact the project at dev@lucene.apache.org to find out where to submit issues.https://issues.apache.org/jira/projects/PYLUCENEI'm trying to build pylucene on Ubuntu but I'm getting an error message which is a little bit opaque. jar lucene-java-9.7.0/lucene/core/build/runtimeJars/lucene-core-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/common/build/runtimeJars/lucene-analysis-common-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/backward-codecs/build/runtimeJars/lucene-backward-codecs-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/classification/build/runtimeJars/lucene-classification-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/codecs/build/runtimeJars/lucene-codecs-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/expressions/build/runtimeJars/lucene-expressions-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/extensions/build/runtimeJars/lucene-extensions-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/facet/build/runtimeJars/lucene-facet-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/grouping/build/runtimeJars/lucene-grouping-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/highlighter/build/runtimeJars/lucene-highlighter-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/join/build/runtimeJars/lucene-join-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/kuromoji/build/runtimeJars/lucene-analysis-kuromoji-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/memory/build/runtimeJars/lucene-memory-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/misc/build/runtimeJars/lucene-misc-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/monitor/build/runtimeJars/lucene-monitor-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/nori/build/runtimeJars/lucene-analysis-nori-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/queries/build/runtimeJars/lucene-queries-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/queryparser/build/runtimeJars/lucene-queryparser-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/sandbox/build/runtimeJars/lucene-sandbox-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/spatial3d/build/runtimeJars/lucene-spatial3d-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/analysis/stempel/build/runtimeJars/lucene-analysis-stempel-9.7.0-SNAPSHOT.jar --jar lucene-java-9.7.0/lucene/suggest/build/runtimeJars/lucene-suggest-9.7.0-SNAPSHOT.jar  --use_full_names --include lucene-java-9.7.0/lucene/expressions/build/runtimeJars/antlr4-runtime-4.11.1.jar --include lucene-java-9.7.0/lucene/expressions/build/runtimeJars/asm-7.2.jar --include lucene-java-9.7.0/lucene/expressions/build/runtimeJars/asm-commons-7.2.jar --include lucene-java-9.7.0/lucene/facet/build/runtimeJars/hppc-0.9.1.jar --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.function --package java.util.regex --package java.io java.io.StringReader --package java.nio.file java.nio.file.Path java.nio.file.Files java.nio.file.Paths --package org.antlr.v4.runtime --package org.antlr.v4.runtime.atn --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --exclude org.apache.lucene.misc.store.WindowsDirectory --exclude org.apache.lucene.misc.store.NativePosixUtil --exclude 'module-info' --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.AbstractCollection 'size:()I' '-:-' --sequence java.util.AbstractList '-:-' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader org.apache.lucene.analysis.Tokenizer:input --version 9.7.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py  --files  --build Illegal option: lTry `jar --help' for more information.Where should I report issues for this project?https://issues.apache.org/jira/projects/PYLUCENEIf you have questions, just ask on pylucene-...@lucene.apache.org.Andi..Thanks.-- Bob Klinehttps://www.rksystems.commailto:bkl...@rksystems.com

[jira] [Closed] (PYLUCENE-31) JCC Parallel/Multiprocess Compilation + Caching

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-31.
--
Resolution: Fixed

distutils is on its way out with Python 3.12

> JCC Parallel/Multiprocess Compilation + Caching
> ---
>
> Key: PYLUCENE-31
> URL: https://issues.apache.org/jira/browse/PYLUCENE-31
> Project: PyLucene
>  Issue Type: Improvement
> Environment: Linux 3.11.0-19-generic #33-Ubuntu SMP x86_64 GNU/Linux
>Reporter: Lee Skillen
>Priority: Minor
>  Labels: build, cache, ccache, distutils, jcc, parallel
> Attachments: feature-parallel-build.patch
>
>
> JCC utilises distutils.Extension() in order to build JCC itself and the 
> packages that it generates for Java wrapping - Unfortunately distutils 
> performs its build sequentially and doesn't take advantage of any additional 
> free cores for parallel building.  As discussed on the list this is likely a 
> design decision due to potential issues that may arise when building projects 
> with awkward, cyclic or recursive dependencies.
> These issues shouldn't appear within JCC-based projects because of the 
> generative nature of the build; i.e. all dependencies are resolved and 
> generated prior to building, and the build process itself is about 
> compilation and construction of the wrapper alone, of which the wrapper files 
> are contained to a sequence of flattened compilation units.
> Enabling this requires monkey patching of distutils, which was also discussed 
> on the list as being a potential source of issues, although we feel that the 
> risk is likely lower than the current setuptools patching utilised.  This 
> would be optional functionality that is also only enabled if the 
> monkey-patching succeeds.  Distutils itself is also part of the standard 
> library and might be less susceptible to change than setuptools, and the area 
> of code monkey patched almost hasn't changed since 2002 (see: 
> http://hg.python.org/cpython/file/tip/Lib/distutils/ccompiler.py).
> In addition to the distutils changes this patch also includes changes to the 
> wrapper class generation to make it more cache friendly, with the target 
> being that no changes in the wrapped code equals no changes in the wrapper 
> code.  So any changes that minimally change the wrapped code mean that with a 
> tool such as ccache the rebuild time would be significantly reduced (almost 
> to a nth, where n is the number of files and only one has changed).
> Obviously the maintainers would have to assess this risk and decide whether 
> they would like to accept the patch or not.  Code has only been tested on 
> Linux with Python 2.7.5 but should gracefully fail and prevent 
> parallelisation if one of the requirements hasn't been met (not on linux, no 
> multiprocessing support, or monkey patching somehow fails).  The change to 
> caching should still benefit everyone regardless.
> Please note that an additional dependency on orderedset has been added to 
> achieve the more deterministic ordering - This may not be desirable (i.e. 
> another package might be desired, such as ordered-set, or the code might be 
> inlined into the package instead), as per maintainer comments.
> --- [following repeated from mailing list] ---
> Performance Statistics :-
> The following are some quick and dirty statistics for building the jcc 
> pylucene itself (incl. java lucene which accounts for about 30-ish seconds 
> upfront) - The JCC files are split using --files 8, and each build is 
> preceded with a make clean:
> Serial (unpatched):
> real5m1.502s
> user5m22.887s
> sys 0m7.749s
> Parallel (patched, 4 physical cores, 8 hyperthreads, 8 parallel jobs):
> real1m37.382s
> user7m16.658s
> sys 0m8.697s
> Furthermore, some additional changes were made to the wrapped file generation 
> to make the generated code more ccache friendly (additional deterministic 
> sorting for methods and some usage of an ordered set).  With these in place 
> and the CC and CCACHE_COMPILERCHECK environment variables set to "ccache gcc" 
> and "content" respectively, and ensuring ccache is installed, subsequent 
> compilation time is reduced again as follows:
> Parallel (patched, 4 physical cores, 8 hyperthreads, 8 parallel jobs, ccache 
> enabled):
> real0m43.051s
> user1m10.392s
> sys 0m4.547s
> This was a run in which nothing changed between runs, so a realistic run in 
> which changes occur it'll be a figure between 0m43.051s and 1m37.382s, 
> depending on how drastic the change was. If many

[jira] [Closed] (PYLUCENE-8) lucene.JCC_VERSION isn't set properly on Windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-8.
-
Resolution: Fixed

> lucene.JCC_VERSION isn't set properly on Windows
> 
>
> Key: PYLUCENE-8
> URL: https://issues.apache.org/jira/browse/PYLUCENE-8
> Project: PyLucene
>  Issue Type: Bug
> Environment: Windows XP, MinGW gcc 4.5, Python 2.6.6, PyLucene 3.0.2
>Reporter: Bill Janssen
>Priority: Minor
>
> After installing 3.0.2 on Win XP with MinGW/msys, I see the following:
> Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] 
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import lucene
> >>> lucene.initVM(classpath=lucene.CLASSPATH)
> 
> >>> lucene.JCC_VERSION
> 'JCC_VER'
> >>> quit()



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (PYLUCENE-18) Version 3.6.0 lacks readme

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-18.
--
Resolution: Fixed

> Version 3.6.0 lacks readme
> --
>
> Key: PYLUCENE-18
> URL: https://issues.apache.org/jira/browse/PYLUCENE-18
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Dion Gillard
>Priority: Minor
>
> Hi,
> It looks like pylucene version 3.6.0 lacks CHANGES in tarball. Also README 
> has followed content:
> {code}
>   Please see doc/documentation/readme.html
> {code}
> At the same there is no docs directory in tarball at all.
> These files are important for linux distributions (like Debian) where they 
> are usually installed to /usr/share/doc



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (PYLUCENE-64) ModuleNotFoundError: No module named 'lucene' when intalling PyLucene

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-64.
--
Resolution: Fixed

seems to work fine

> ModuleNotFoundError: No module named 'lucene' when intalling PyLucene
> -
>
> Key: PYLUCENE-64
> URL: https://issues.apache.org/jira/browse/PYLUCENE-64
> Project: PyLucene
>  Issue Type: Bug
>Reporter: anis amirouche
>Priority: Major
>
> I'm trying to install Pylucene 8.11.0 on mac os. the jcc is built and 
> installed successfully, but from pylucene folder when running make test i'm 
> encountering the following error : ModuleNotFoundError: No module named 
> 'lucene', please note the make command is successfull.
> please can anyone help me with solving this error. I don't even understand 
> what i'm doing wrong, it's like lucene is not installed, and i'm having this 
> error with all the files of pylucene. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (PYLUCENE-56) Can't build JCC on Mac

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda closed PYLUCENE-56.
--
Resolution: Fixed

building JCC on M2 mac works fine

> Can't build JCC on Mac
> --
>
> Key: PYLUCENE-56
> URL: https://issues.apache.org/jira/browse/PYLUCENE-56
> Project: PyLucene
>  Issue Type: Bug
> Environment: MacOSX 10.15.7, Intel Core i7, Python 3.8.2, gcc 
> (Homebrew GCC 10.2.0_3) 10.2.0
> following the instructions here:
> http://lucene.apache.org/pylucene/jcc/install.html
> svn co https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc jcc
> Checked out revision 1886645.
>Reporter: Clem Wang
>Priority: Major
>  Labels: build
>
> This is puzzling to me, as I can't figure out how the failing gcc command 
> line gets its arguments (mostly).  I found one problem in the setup.py, but I 
> can't find the error causing strings anywhere in the files in the jcc 
> directory of sub directory.
>  
> Steps:
>  
> {code:java}
> svn co https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc jcc
> Checked out revision 1886645.
> cd jcc
> python setup.py build
>  
> {code}
> ...
> /opt/local/bin/gcc -Wno-unused-result -Wsign-compare -Wunreachable-code 
> -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall 
> {color:#ff}*-iwithsysroot/*{color}System/Library/Frameworks/System.framework/PrivateHeaders
>  
> {color:#ff}*-iwithsysroot/*{color}Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers
>  {color:#ff}*-arch arm64*{color} -arch x86_64 
> -I/usr/local/opt/libomp/include -Xpreprocessor -fopenmp -dynamiclib 
> -D_jcc_lib -DJCC_VER="3.8" 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include/darwin
>  -I_jcc3 -Ijcc3/sources -I/Users/cwang/3.7/include 
> -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/include/python3.8
>  -c jcc3/sources/jcc.cpp -o 
> build/temp.macosx-10.14.6-x86_64-3.8/jcc3/sources/jcc.o -DPYTHON 
> -fno-strict-aliasing -Wno-write-strings -mmacosx-version-min=10.9 -std=c++11  
> {color:#ff}*-stdlib=libc++*{color}
>  
> which generates 4 errors due to the parts marked above in red bold:
>  
> *gcc:* *error:* this compiler does not support arm64
> *gcc:* *error:* unrecognized command-line option 
> '*-iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders*'
> *gcc:* *error:* unrecognized command-line option 
> '*-iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers*'
> *gcc:* *error:* unrecognized command-line option '*-stdlib=libc++*'
> error: command '/opt/local/bin/gcc' failed with exit status 1
>  
> Obviously, the contradictory 
> *-arch arm64*
> needs to be removed but I can't find arm64 anywhere.
>  
> The unnecessary
> *-stdlib=libc++*
>  
> can be removed from setup.py:
> {code:java}
> CFLAGS = {
>  'darwin': ['-fno-strict-aliasing', '-Wno-write-strings',
>  '-mmacosx-version-min=10.9', '-std=c++11', '-stdlib=libc++'],{code}
>  
> After poking around, I figured out that gcc uses
> {code:java}
> -I {code}
> not
> {code:java}
> -i {code}
> for includes.
>  
> Making these modifications (and adding
> {code:java}
> -Wno-attributes{code}
> to remove warnings)
>  
> I came up with this line that does successfully compile without errors:
> /opt/local/bin/gcc -Wno-attributes -Wno-unused-result -Wsign-compare 
> -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall 
> -I/System/Library/Frameworks/System.framework/PrivateHeaders 
> -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers
>  -arch x86_64 -I/usr/local/opt/libomp/include -Xpreprocessor -fopenmp 
> -dynamiclib -D_jcc_lib -DJCC_VER="3.8" 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include 
> -I/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/include/darwin
>  -I_jcc3 -Ijcc3/sources -I/Users/cwang/3.7/include 
> -I/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/include/python3.8
>  -c jcc3/sources/jcc.cpp -o 
> build/temp.macosx-10.14.6-x86_64-3.8/jcc3/sources/jcc.o -DPYTHON 
> -fno-strict-aliasing -Wno-write-strings -mmacosx-version-min=10.9 -std=c++11
>  
> But other than removing  *'-stdlib=libc++'*  from the setup.py file I have no 
> idea how to modify things to fix the compile errors by the line generated 
> some how by setup.py



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-27) JCC should be able to create sdist archives

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785231#comment-17785231
 ] 

Andi Vajda commented on PYLUCENE-27:


Yes, with the upcoming demise of setuptools/distutils, this issue may get 
resolution.
Instead of invoking setuptools.setup() produce something that pypa/build can 
use as input, some yaml maybe ?

> JCC should be able to create sdist archives
> ---
>
> Key: PYLUCENE-27
> URL: https://issues.apache.org/jira/browse/PYLUCENE-27
> Project: PyLucene
>  Issue Type: Wish
> Environment: jcc-svn-head
>Reporter: Martin Scherer
>Priority: Major
> Attachments: createSetupScript.patch
>
>
> I was not able to create a complete (in terms one is able to compile and 
> install the desired wrapper) source distribution.
> I've tried following calls:
>   python -m jcc --jar foo  --egg-info --extra-setup-arg sdist
> and
>  python -m jcc --jar foo --extra-setup-arg sdist
> Both create archives only containing the egg-info and setup.py but no source 
> code at all.
> I really need this feature for my testing environment with tox, since this 
> heavily depends on the sdist feature.
> thanks,
> best,
> Martin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-69) Linking libjvm seems to prevent PyPi upload

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785230#comment-17785230
 ] 

Andi Vajda edited comment on PYLUCENE-69 at 11/11/23 10:54 PM:
---

JCC is a python/c++ code generator for wrapping Java libraries using JNI. Any 
JCC-built Python extension embeds a Java Virtual Machine. If PyPI doesn't allow 
you to upload libjvm.so then you cannot ship JCC-produced binaries on PyPI. 
Only source distributions are then possible. And yes, building binaries can 
take time and requires that at least a C++ compiler be present as well. 
Knowledge how to operate a C++ compiler and linker is also useful.
I think you should reset your expectation a bit here.
Even _if_ you could do this, the wheel would be enormous: the number of Python 
* C++ * Java * OS versions possible makes for a lot of combos. There is a 
reason I don't ever ship binaries, it's just too much (!)


was (Author: vajda):
JCC is a python/c++ code generator for wrapping Java libraries using JNI. Any 
JCC-built Python extension embeds a Java Virtual Machine. If PyPI doesn't allow 
you to upload libjvm.so then you cannot ship JCC-produced binaries on PyPI. 
Only source distributions are then possible. And yes, building binaries can 
take time and requires that at least a C++ compiler be present as well. 
Knowledge how to operate a C++ compiler and linker is also useful.
I think you should reset your expectation a bit here.
Even _if_ could do this, the wheel would be enormous: the number of Python * 
C++ * Java * OS versions possible makes for a lot of combos. There is a reason 
I don't ever ship binaries, it's just too much (!)

> Linking libjvm seems to prevent PyPi upload
> ---
>
> Key: PYLUCENE-69
> URL: https://issues.apache.org/jira/browse/PYLUCENE-69
> Project: PyLucene
>  Issue Type: Question
>Reporter: Clément Jonglez
>Priority: Major
>
> As mentioned in 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] , I am 
> trying to package the Orekit Python wrapper from [~petrush] (which uses JCC) 
> to PyPi.
> I used the --wheel option to compile a wheel and not an egg, and I tried to 
> upload the wheel to PyPi.
> But PyPi refuses my wheel with the answer :
> {noformat}
> Binary wheel 'orekit-11.3.3-cp312-cp312-linux_x86_64.whl' has an unsupported 
> platform tag 'linux_x86_64'. {noformat}
> After reading about why this error occurs ( 
> [https://peps.python.org/pep-0513/#rationale] )  , I tried to convert the 
> wheel to a manylinux wheel by using:
>  
> {code:java}
> auditwheel repair dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned the following error:
>  
> {noformat}
> auditwheel: error: cannot repair 
> "dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl" to "manylinux_2_5_x86_64" 
> ABI because of the presence of too-recent versioned symbols. You'll need to 
> compile the wheel on an older toolchain.{noformat}
>  
> I then ran the following command to get more information about which symbols 
> are problematic in the wheel:
>  
> {code:java}
> auditwheel-symbols --manylinux 2_34 
> dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned:
>  
> {noformat}
> orekit/_orekit.cpython-312-x86_64-linux-gnu.so is not manylinux_2_34 
> compliant because it links the following forbidden libraries:
> libjvm.so{noformat}
>  
>  
> I tried removing -ljvm from the LFLAGS list in jcc's config.py, but as 
> expected the Python program then fails on starting the JVM:
> {noformat}
> Traceback (most recent call last):
>   File "/media/ssd/git/orekit_python_artifacts/test/AbstractDetectorTest.py", 
> line 3, in 
>     import orekit
>   File 
> "/home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/__init__.py",
>  line 7, in 
>     from . import _orekit
> ImportError: 
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/_orekit.cpython-312-x86_64-linux-gnu.so:
>  undefined symbol: JNI_GetDefaultJavaVMInitArgs{noformat}
>  
> I don't have any more clues... Alternatively, I could try to package the 
> Orekit Python wrapper as a source distribution (using 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-27] and 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] ), but 
> this would mean that a user would need to wait approx. 10 minutes for the 
> wheel to compile when running pip install...
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-69) Linking libjvm seems to prevent PyPi upload

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785230#comment-17785230
 ] 

Andi Vajda commented on PYLUCENE-69:


JCC is a python/c++ code generator for wrapping Java libraries using JNI. Any 
JCC-built Python extension embeds a Java Virtual Machine. If PyPI doesn't allow 
you to upload libjvm.so then you cannot ship JCC-produced binaries on PyPI. 
Only source distributions are then possible. And yes, building binaries can 
take time and requires that at least a C++ compiler be present as well. 
Knowledge how to operate a C++ compiler and linker is also useful.
I think you should reset your expectation a bit here.
Even _if_ could do this, the wheel would be enormous: the number of Python * 
C++ * Java * OS versions possible makes for a lot of combos. There is a reason 
I don't ever ship binaries, it's just too much (!)

> Linking libjvm seems to prevent PyPi upload
> ---
>
> Key: PYLUCENE-69
> URL: https://issues.apache.org/jira/browse/PYLUCENE-69
> Project: PyLucene
>  Issue Type: Question
>Reporter: Clément Jonglez
>Priority: Major
>
> As mentioned in 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] , I am 
> trying to package the Orekit Python wrapper from [~petrush] (which uses JCC) 
> to PyPi.
> I used the --wheel option to compile a wheel and not an egg, and I tried to 
> upload the wheel to PyPi.
> But PyPi refuses my wheel with the answer :
> {noformat}
> Binary wheel 'orekit-11.3.3-cp312-cp312-linux_x86_64.whl' has an unsupported 
> platform tag 'linux_x86_64'. {noformat}
> After reading about why this error occurs ( 
> [https://peps.python.org/pep-0513/#rationale] )  , I tried to convert the 
> wheel to a manylinux wheel by using:
>  
> {code:java}
> auditwheel repair dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned the following error:
>  
> {noformat}
> auditwheel: error: cannot repair 
> "dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl" to "manylinux_2_5_x86_64" 
> ABI because of the presence of too-recent versioned symbols. You'll need to 
> compile the wheel on an older toolchain.{noformat}
>  
> I then ran the following command to get more information about which symbols 
> are problematic in the wheel:
>  
> {code:java}
> auditwheel-symbols --manylinux 2_34 
> dist/orekit-11.3.3-cp312-cp312-linux_x86_64.whl{code}
>  
> Which returned:
>  
> {noformat}
> orekit/_orekit.cpython-312-x86_64-linux-gnu.so is not manylinux_2_34 
> compliant because it links the following forbidden libraries:
> libjvm.so{noformat}
>  
>  
> I tried removing -ljvm from the LFLAGS list in jcc's config.py, but as 
> expected the Python program then fails on starting the JVM:
> {noformat}
> Traceback (most recent call last):
>   File "/media/ssd/git/orekit_python_artifacts/test/AbstractDetectorTest.py", 
> line 3, in 
>     import orekit
>   File 
> "/home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/__init__.py",
>  line 7, in 
>     from . import _orekit
> ImportError: 
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/orekit-12.0-py3.12-linux-x86_64.egg/orekit/_orekit.cpython-312-x86_64-linux-gnu.so:
>  undefined symbol: JNI_GetDefaultJavaVMInitArgs{noformat}
>  
> I don't have any more clues... Alternatively, I could try to package the 
> Orekit Python wrapper as a source distribution (using 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-27] and 
> [https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-68] ), but 
> this would mean that a user would need to wait approx. 10 minutes for the 
> wheel to compile when running pip install...
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-68) setup.py install and easy_install command are deprecated

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785219#comment-17785219
 ] 

Andi Vajda commented on PYLUCENE-68:


I was afraid of that...
I did try to build jcc with pypa/build and it seems to work just fine:
{code:java}
$ cd jcc
$ python3 -m build
$ python3 -m pip install dist/JCC-3.13-cp312-cp312-macosx_13_0_arm64.whl{code}
worked fine.
Then, I get the warnings you reported when running "jcc ... --install" from 
pylucene's Makefile are due to jcc's calling setuptools.setup() function to 
build the extension it generated.
Do you know of a migration guide from setuptools.setup() to calling similar 
stuff in pypa/build ?

> setup.py install and easy_install command are deprecated
> 
>
> Key: PYLUCENE-68
> URL: https://issues.apache.org/jira/browse/PYLUCENE-68
> Project: PyLucene
>  Issue Type: Improvement
>Reporter: Clément Jonglez
>Priority: Major
>
> When compiling with jcc to create a wheel, I get the following warnings (see 
> below).
> This is still working but eventually the `setup.py` installation and 
> `easy_install` command will be removed.
> It would be nice to adapt JCC to modern pypa build tools, but I don't know 
> enough about JCC to do these changes.
>  
> {noformat}
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/dist.py:947:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  SetuptoolsDeprecationWarning: setup.py install is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` directly.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html 
> for details.
>         
> 
> !!
>   self.initialize_options()
> /home/yzokras/Documents/orekit-pip/orekit312/lib/python3.12/site-packages/setuptools/_distutils/cmd.py:66:
>  EasyInstallDeprecationWarning: easy_install command is deprecated.
> !!
>         
> 
>         Please avoid running ``setup.py`` and ``easy_install``.
>         Instead, use pypa/build, pypa/installer or other
>         standards-based tools.
>         See https://github.com/pypa/setuptools/issues/917 for details.
>         
> 
> !!
>   self.initialize_options()
>  
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release PyLucene 9.7.0-rc1

[Andi Vajda]

This vote has passed !
Thank you everyone who voted, release artifacts should be available shortly...

Andi..

> On Jul 12, 2023, at 21:45, Michael McCandless  
> wrote:
> 
> +1
> 
> I ran the same exciting smoke test -- indexing first 100K enwiki docs,
> running a few political searches, force merging, searching again.
> Everything ran fine!
> 
> Arch Linux kernel 6.3.2, Java 17.0.7+7, Python 3.11.3.
> 
> Sorry for the delay!
> 
> Mike
> 
>> On Sun, Jul 9, 2023 at 3:28 PM Dawid Weiss  wrote:
>> 
>> 
>> +1 to release. Thanks Andi.
>> 
>>> On Thu, Jul 6, 2023 at 9:47 AM Andi Vajda  wrote:
>>> 
>>> 
>>> The PyLucene 9.7.0 (rc1) release tracking the recent release of
>>> Apache Lucene 9.7.0 is ready.
>>> 
>>> A release candidate is available from:
>>>https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.7.0-rc1/
>>> 
>>> PyLucene 9.7.0 is built with JCC 3.13, included in these release
>>> artifacts.
>>> 
>>> JCC 3.13 supports Python 3.3 up to Python 3.11.
>>> PyLucene may also be built with Python 2 but this configuration is no
>>> longer
>>> tested.
>>> 
>>> Please vote to release these artifacts as PyLucene 9.7.0.
>>> Anyone interested in this release can and should vote !
>>> 
>>> Thanks !
>>> 
>>> Andi..
>>> 
>>> ps: the KEYS file for PyLucene release signing is at:
>>> https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
>>> https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS
>>> 
>>> pps: here is my +1
>>> 
>> --
> Mike McCandless
> 
> http://blog.mikemccandless.com

Re: Unable to install Pylucene

[Andi Vajda]

> On Jul 8, 2023, at 12:58, Subinay Adhikary  wrote:
> 
> 
> Dear sir,
>  I encountered difficulties while attempting to install 
> Pylucene (version 8.10.0) on my Linux machine. Despite having installed JCC, 
> I encountered an unresolved error even after multiple attempts. I have 
> attached a screenshot also.

Screenshots don't make it to this list. 

Andi..

> Thanks and regards,
> Subinay Adhikary

Re: New release for PyLucene?

[Andi Vajda]

On Wed, 5 Jul 2023, Benjamin Trent wrote:


Lucene 9.7 was just released and contains multiple desirable improvements:
https://lucene.apache.org/core/9_7_0/changes/Changes.html

Could we kick off a new release for PyLucene?


We prepared a 9.7.0 release candidate here [1] and kicked off a release 
vote thread. Please vote !


Thanks !

Andi..

[1] https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.7.0-rc1/

[VOTE] Release PyLucene 9.7.0-rc1

[Andi Vajda]

The PyLucene 9.7.0 (rc1) release tracking the recent release of
Apache Lucene 9.7.0 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.7.0-rc1/

PyLucene 9.7.0 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2 but this configuration is no longer
tested.

Please vote to release these artifacts as PyLucene 9.7.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Commented] (PYLUCENE-28) JCC reuses JVM instances in impl, if compile() is called twice.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736851#comment-17736851
 ] 

Andi Vajda commented on PYLUCENE-28:


I see 2 things:

  - if a constructor takes no arguments, like 
org.apache.lucene.document.Document(), then anything passed to it is ignored.
  - all constructor wrappers have a kwds parameter but it's ignored.

Both could be fixed at the cost of extra code that raises an error if kwds is 
not empty.
Also, extra code would have to be generated for checking that args is empty for 
contructores not taking any args.
Is it worth it ?

> JCC reuses JVM instances in impl, if compile() is called twice.
> ---
>
> Key: PYLUCENE-28
> URL: https://issues.apache.org/jira/browse/PYLUCENE-28
> Project: PyLucene
>  Issue Type: Improvement
> Environment: jcc-svn-head (2.18-pre)
>Reporter: Martin Scherer
>Priority: Blocker
>  Labels: patch
> Attachments: jvm_instance_check.patch
>
>
> If you import jcc.cpp to call compile yourself (a wrapped setup.py script to 
> generate a wrapper on the fly, which seems to be a common use case), the 
> current version complains about the JVM already being initialized before.
> The patch first checks for a running instance and creates one, if none is 
> being found.
> For myself, this is a blocker, since it raises otherwise.
> Best, 
> Martin



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release PyLucene 9.6.0-rc1

[Andi Vajda]

On Fri, 2 Jun 2023, Dawid Weiss wrote:


Late, but +1 to release.

Thank you Andi!


Thank you Dawid and Michael, this vote has passed !
Preparing release...

Andi..



Dawid


On Tue, May 30, 2023 at 1:44 AM Andi Vajda  wrote:



The PyLucene 9.6.0 (rc1) release tracking the recent release of
Apache Lucene 9.6.0 is ready.

A release candidate is available from:
https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.6.0-rc1/

PyLucene 9.6.0 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2 but this configuration is no
longer
tested.

Please vote to release these artifacts as PyLucene 9.6.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[VOTE] Release PyLucene 9.6.0-rc1

[Andi Vajda]

The PyLucene 9.6.0 (rc1) release tracking the recent release of
Apache Lucene 9.6.0 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.6.0-rc1/

PyLucene 9.6.0 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2 but this configuration is no longer
tested.

Please vote to release these artifacts as PyLucene 9.6.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: PyLucene installation - make failing

[Andi Vajda]

On Tue, 28 Mar 2023, S Less wrote:


I'm able to successfully perform indexing and searching within Python.
I was hoping to try the Monitor

class however this line fails

from org.apache.lucene.monitor import Monitor

Traceback (most recent call last):
 File "/Users/akeers/Documents/git_work/pylucene-test/test2.py", line 2,
in 
   from org.apache.lucene.monitor import Monitor
ModuleNotFoundError: No module named 'org.apache.lucene.monitor';
'org.apache.lucene' is not a package


Indeed, the org.apache.lucene.monitor package is not built into PyLucene.
Why ? I didn't know about it.

Here is a diff you can apply to Makefile to get the Monitor stuff included 
in PyLucene:


-- SNIP --
Index: Makefile
===
--- Makefile(revision 1904983)
+++ Makefile(working copy)
@@ -97,6 +97,7 @@
 JARS+=$(KUROMOJI_JAR)   # japanese analyzer module
 JARS+=$(MEMORY_JAR) # single-document memory index
 JARS+=$(MISC_JAR)   # misc
+JARS+=$(MONITOR_JAR)# monitor
 JARS+=$(MORFOLOGIK_JAR) # morfologik analyzer module
 JARS+=$(NORI_JAR)   # korean analyzer module
 #JARS+=$(PHONETIC_JAR)   # phonetic analyzer module
@@ -135,6 +136,7 @@
 
KUROMOJI_JAR=$(LUCENE)/analysis/kuromoji/build/runtimeJars/lucene-analysis-kuromoji-$(LUCENE_VER)-SNAPSHOT.jar
 
MEMORY_JAR=$(LUCENE)/memory/build/runtimeJars/lucene-memory-$(LUCENE_VER)-SNAPSHOT.jar
 
MISC_JAR=$(LUCENE)/misc/build/runtimeJars/lucene-misc-$(LUCENE_VER)-SNAPSHOT.jar
+MONITOR_JAR=$(LUCENE)/monitor/build/runtimeJars/lucene-monitor-$(LUCENE_VER)-SNAPSHOT.jar
 
NORI_JAR=$(LUCENE)/analysis/nori/build/runtimeJars/lucene-analysis-nori-$(LUCENE_VER)-SNAPSHOT.jar
 
PHONETIC_JAR=$(LUCENE)/analysis/phonetic/build/runtimeJars/lucene-analysis-phonetic-$(LUCENE_VER)-SNAPSHOT.jar
 
QUERIES_JAR=$(LUCENE)/queries/build/runtimeJars/lucene-queries-$(LUCENE_VER)-SNAPSHOT.jar
-- SNIP --

Andi..

Re: PyLucene installation - make failing

[Andi Vajda]

I suspect you didn't edit Makefile to enable the variables corresponding to 
your environment ?

Andi..

> On Mar 23, 2023, at 01:02, S Less  wrote:
> 
> Hi, as you can see below, make and make test are reporting *Illegal option:
> l*
> 
> and make test an additional error.
> 
> macOS Ventura Version 13.2.1
> 
> Thanks, Al
> 
> 
> 
> username@MacBook-Pro pylucene-9.4.1 % make
> 
> (cd lucene-java-9.4.1; ./gradlew collectRuntimeJars)
> 
> Downloading https://services.gradle.org/distributions/gradle-7.3.3-all.zip
> 
> ...10%...20%...30%...40%...50%...60%70%...80%...90%...100%
> 
> 
> Welcome to Gradle 7.3.3!
> 
> 
> Here are the highlights of this release:
> 
> - Easily declare new test suites in Java projects
> 
> - Support for Java 17
> 
> - Support for Scala 3
> 
> 
> For more details see https://docs.gradle.org/7.3.3/release-notes.html
> 
> 
> To honour the JVM settings for this build a single-use Daemon process will
> be forked. See
> https://docs.gradle.org/7.3.3/userguide/gradle_daemon.html#sec:disabling_the_daemon
> .
> 
> Daemon will be stopped at the end of the build
> 
> 
> *> Task :localSettings*
> 
> 
> IMPORTANT. This is the first time you ran the build. I wrote some sane
> defaults (for this machine) to 'gradle.properties', they will be picked up
> on consecutive gradle invocations (not this one).
> 
> 
> Run gradlew :helpLocalSettings for more information.
> 
> 
> *> Task :errorProneSkipped*
> 
> WARNING: errorprone disabled (skipped on builds not running inside CI
> environments, pass -Pvalidation.errorprone=true to enable)
> 
> 
> *> Task :lucene:core:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:backward-codecs:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:facet:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:memory:compileJava*
> 
> Note:
> /Users/username/Downloads/pylucene-9.4.1/lucene-java-9.4.1/lucene/memory/src/java/org/apache/lucene/index/memory/MemoryIndex.java
> uses or overrides a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:queries:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:sandbox:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:analysis:common:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:codecs:compileJava*
> 
> Note:
> /Users/username/Downloads/pylucene-9.4.1/lucene-java-9.4.1/lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextDocValuesReader.java
> uses or overrides a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:extensions:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:misc:compileJava*
> 
> Note:
> /Users/username/Downloads/pylucene-9.4.1/lucene-java-9.4.1/lucene/misc/src/java/org/apache/lucene/misc/util/fst/UpToTwoPositiveIntOutputs.java
> uses or overrides a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *> Task :lucene:test-framework:compileJava*
> 
> Note: Some input files use or override a deprecated API.
> 
> Note: Recompile with -Xlint:deprecation for details.
> 
> 
> *BUILD SUCCESSFUL* in 4m 26s
> 
> 123 actionable tasks: 123 executed
> 
> ICU not installed
> 
> jar
> lucene-java-9.4.1/lucene/core/build/runtimeJars/lucene-core-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/analysis/common/build/runtimeJars/lucene-analysis-common-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/backward-codecs/build/runtimeJars/lucene-backward-codecs-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/classification/build/runtimeJars/lucene-classification-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/codecs/build/runtimeJars/lucene-codecs-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/expressions/build/runtimeJars/lucene-expressions-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/extensions/build/runtimeJars/lucene-extensions-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/facet/build/runtimeJars/lucene-facet-9.4.1-SNAPSHOT.jar
> --jar
> lucene-java-9.4.1/lucene/grouping/build/runtimeJars/lucene-grouping-9.4.1-SNAPSHOT.jar
> --jar
> 

Re: JCC Compilation Error

[Andi Vajda]

On Thu, 23 Mar 2023, S Less wrote:


*jcc3/sources/functions.cpp:1742:28: **error: **expression is not
assignable*

   Py_TYPE(*type) = PY_TYPE(FinalizerClass);

*~~ ^*


This is https://issues.apache.org/jira/browse/PYLUCENE-66 and was fixed for 
PyLucene 9.4.1.
You say "I am running setup.py from the latest PyLucene download", is that 
9.4.1 ?


Andi..

Re: Adding new extension point

[Andi Vajda]

On Thu, 10 Nov 2022, Benjamin Trent wrote:


Hey y'all,

I am new to this type of workflow, I am used to github and Pull-requests.

What is the process for adding a new extension point? With a recent foray
into getting Lucene KNN into the ann-benchmarks repository, I found the
need to adjust the current codec (Lucene94Codec) to allow us to adjust some
values.

I think the extension will only need to allow us to optionally override the
`getFormat...ForField` parameters.


Technically:
  - see how it's done by looking at the code tree in PyLucene's extensions
directory tree where the native extension points are defined and add
yours there - then see how they're used in PyLucene's Python unit tests
where the actual extension points are implemented in Python

Procedurally (assuming you want your change maintained in the PyLucene code 
base):

  - explain the benefits for it to be part of the PyLucene codebase and
how it'll be maintained as Lucene's codebase evolves
  - open an issue on Jira [1] and attach a patch or send the code changes as
a patch file to the list directly

Andi..

[1] 
https://issues.apache.org/jira/projects/PYLUCENE/issues/PYLUCENE-28?filter=allopenissues

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

> On Nov 9, 2022, at 01:52, Uwe Schindler  wrote:
> 
> Hi Andi,
> 
>> I did that now, and wouldn't have if someone had told me about the branch 
>> change.
> 
> Normally before you push the branch and edit anything, you should do a "git 
> pull" to get latest changes from server. A "git pull" fails with error 
> message if the branch does not exist on server. So normally you would notice 
> the issue. It is exactly like with Subversion, if you update a branch there 
> that no longer exists, you get a 404. The only difference (and that's the 
> pain) on Git: if you push a non-existing branch, it is created on server 
> automatically.
> 
> We changed from master to main long ago, I think at latest when we splitted 
> Lucene/Solr. Sorry for not informing you.

Well, I made a release against 'master' in April of this year and nothing broke 
then.

>>> I will check how to setup branch protection to not allow pushing a master 
>>> branch.
>> 
>> I no longer have a master branch on my system.
> 
> Great!
> 
> No problem, it seems all well again,

Good, thank you for catching and fixing this and sorry for the noise.

Andi..

> 
> Uwe
> 
>> Andi..
>> 
>>> 
>>> Uwe
>>> 
>>> Am 09.11.2022 um 01:42 schrieb Uwe Schindler:
 Hi Andi,
 
 you pushed the "master" branch to lucene-site Git repo, which was outdated 
 and was no longer existing on server. I deleted it because main AND master 
 cause issues with website build and makes it hard to understand what needs 
 to be changed for website updates. Please push your changes to "main" 
 branch! The problem with duplicate branches is that your push removed some 
 stuff from the website.
 
 Your last push was yesterday and that caused havoc: it removed our latest 
 releases from web page because you were overwriting it with an old version.
 
 Please cleanup your local repo and use "main" branch instead. I don't know 
 what changes are now lost by deleting the branch on server. Please add 
 your release of python lucene again on correct branch.
 
 Uwe
 
> Am 28.04.2022 um 02:02 schrieb va...@apache.org:
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> vajda pushed a change to branch master
>> in repository https://gitbox.apache.org/repos/asf/lucene-site.git
>> 
>> 
>>at 038f44716 release 9.1.0
>> 
>> This branch includes the following new commits:
>> 
>>   new 038f44716 release 9.1.0
>> 
>> The 1 revisions listed above as "new" are entirely new to this
>> repository and will be described in separate emails.  The revisions
>> listed as "add" were already present in the repository and have only
>> been added to this reference.
>> 
>>> -- 
>>> Uwe Schindler
>>> Achterdiek 19, D-28357 Bremen
>>> https://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Confusing to have main and master branches in lucene-site

[Andi Vajda]

On Wed, 9 Nov 2022, Uwe Schindler wrote:


Ok I deleted it, BUT:

the branch was pushed by Andi in error as he had an old version of master 
branch still on his computer. This also caused issues with website build.


I asked him to redo his changes on correct branch by checking what he 
committed. I think we should add a branch protection.


Yes, my bad here, but I didn't know we switched branches. I updated my notes 
for making a release accordingly. They now say to use branches 'main' and 
'production'.


Andi..



Uwe

Am 09.11.2022 um 01:26 schrieb Uwe Schindler:

I think we forgot to remove it. I will do that in a moment.

Uwe

Am 09.11.2022 um 00:43 schrieb sebb:

The https://github.com/apache/lucene-site repo has both main and
master branches.

This is confusing.

Are both still in use?

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

On Wed, 9 Nov 2022, Uwe Schindler wrote:

I was able to merge the missing changes into the main branch from production. 
It should be uptodate now. There was some hickup with asf.yaml, too, but 
should be ok now. Website was rebuilt.


Thank you for fixing this !

Please please make sure to NOT push to master branch anymore! Please switch 
to main and pull changes before editing. And delete your local "master" 
branch, too.


I did that now, and wouldn't have if someone had told me about the branch 
change.


I will check how to setup branch protection to not allow pushing a master 
branch.


I no longer have a master branch on my system.

Andi..



Uwe

Am 09.11.2022 um 01:42 schrieb Uwe Schindler:

Hi Andi,

you pushed the "master" branch to lucene-site Git repo, which was outdated 
and was no longer existing on server. I deleted it because main AND master 
cause issues with website build and makes it hard to understand what needs 
to be changed for website updates. Please push your changes to "main" 
branch! The problem with duplicate branches is that your push removed some 
stuff from the website.


Your last push was yesterday and that caused havoc: it removed our latest 
releases from web page because you were overwriting it with an old version.


Please cleanup your local repo and use "main" branch instead. I don't know 
what changes are now lost by deleting the branch on server. Please add your 
release of python lucene again on correct branch.


Uwe

Am 28.04.2022 um 02:02 schrieb va...@apache.org:

This is an automated email from the ASF dual-hosted git repository.

vajda pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/lucene-site.git


   at 038f44716 release 9.1.0

This branch includes the following new commits:

  new 038f44716 release 9.1.0

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

On Tue, 8 Nov 2022, Andi Vajda wrote:


Hi Uwe,

On Wed, 9 Nov 2022, Uwe Schindler wrote:

you pushed the "master" branch to lucene-site Git repo, which was outdated 
and was no longer existing on server. I deleted it because main AND master 
cause issues with website build and makes it hard to understand what needs 
to be changed for website updates. Please push your changes to "main" 
branch! The problem with duplicate branches is that your push removed some 
stuff from the website.


Your last push was yesterday and that caused havoc: it removed our latest 
releases from web page because you were overwriting it with an old version.


Please cleanup your local repo and use "main" branch instead. I don't know 
what changes are now lost by deleting the branch on server. Please add your 
release of python lucene again on correct branch.


My notes said to use the 'master' branch. I can change my notes to use 'main' 
but I need to be told first (!)


All changes are on the 'production' branch as well, so things need not have 
been completely lost ?


My git-fu is limited so I can't reconstruct stuff from git, purely, but I can 
make sure the PyLucene stuff is current in the 'main' and 'production' 
branches. I've now updated my notes to use 'main'.


I did the following in lucene-site.git
  - git checkout main
  - git pull
  - git branch -D master
  - git branch
* main
  production
I then checked the content/pylucene/pylucene_news, content/pages/pylucene
directories as well as the content/pylucene/doap.rdf file (which I fixed 
this morning for a XML tag (my bad)).

All looks fine.
For good measure, I also checked the production branch and it looks fine 
too.


Andi..

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [lucene-site] branch master created (now 038f44716)

[Andi Vajda]

 Hi Uwe,

On Wed, 9 Nov 2022, Uwe Schindler wrote:

you pushed the "master" branch to lucene-site Git repo, which was outdated 
and was no longer existing on server. I deleted it because main AND master 
cause issues with website build and makes it hard to understand what needs to 
be changed for website updates. Please push your changes to "main" branch! 
The problem with duplicate branches is that your push removed some stuff from 
the website.


Your last push was yesterday and that caused havoc: it removed our latest 
releases from web page because you were overwriting it with an old version.


Please cleanup your local repo and use "main" branch instead. I don't know 
what changes are now lost by deleting the branch on server. Please add your 
release of python lucene again on correct branch.


My notes said to use the 'master' branch. I can change my notes to use 
'main' but I need to be told first (!)


All changes are on the 'production' branch as well, so things need not have 
been completely lost ?


My git-fu is limited so I can't reconstruct stuff from git, purely, but I 
can make sure the PyLucene stuff is current in the 'main' and 'production' 
branches. I've now updated my notes to use 'main'.


Andi..



Uwe

Am 28.04.2022 um 02:02 schrieb va...@apache.org:

This is an automated email from the ASF dual-hosted git repository.

vajda pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/lucene-site.git


   at 038f44716 release 9.1.0

This branch includes the following new commits:

  new 038f44716 release 9.1.0

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Fwd: Error when processing doap file https://lucene.apache.org/pylucene/doap.rdf:

[Andi Vajda]

On Tue, 8 Nov 2022, sebb wrote:


Please fix the broken tag here:

https://github.com/apache/lucene-site/blob/7b2112e47026270eac3146d1f46cace64192a144/content/pylucene/doap.rdf#L45


Done, sorry for the breakage.

Andi..



-- Forwarded message -
From: Projects 
Date: Tue, 8 Nov 2022 at 02:00
Subject: Error when processing doap file
https://lucene.apache.org/pylucene/doap.rdf:
To: Site Development 


URL: https://lucene.apache.org/pylucene/doap.rdf
mismatched tag: line 46, column 8
Source: 
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release PyLucene 9.4.1-rc3

[Andi Vajda]

This vote has passed.
Thank you all who voted !

The PyLucene 9.4.1 is now available (or when the download mirrors show it).

Andi..

On Tue, 1 Nov 2022, Andi Vajda wrote:



The PyLucene 9.4.1 (rc3) release tracking the recent release of
Apache Lucene 9.4.1 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.4.1-rc3/

PyLucene 9.4.1 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2, although Python 2 support is now 
untested.


Please vote to release these artifacts as PyLucene 9.4.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Comment Edited] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629184#comment-17629184
 ] 

Andi Vajda edited comment on PYLUCENE-66 at 11/4/22 7:52 PM:
-

See code for installType() function in this file:
[https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc3/sources/functions.cpp]

 


was (Author: vajda):
The installType function in jcc/jcc3/sources/functions.cpp is supposed to be

{{
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
}}

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629184#comment-17629184
 ] 

Andi Vajda edited comment on PYLUCENE-66 at 11/4/22 7:50 PM:
-

The installType function in jcc/jcc3/sources/functions.cpp is supposed to be

{{
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
}}


was (Author: vajda):
The installType function in jcc/jcc3/sources/functions.cpp is supposed to be
```
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
```



> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629184#comment-17629184
 ] 

Andi Vajda commented on PYLUCENE-66:


The installType function in jcc/jcc3/sources/functions.cpp is supposed to be
```
void installType(PyTypeObject **type, PyType_Def *def,
 PyObject *module, char *name, int isExtension)
{
if (*type == NULL)
{
*type = makeType(def);

if (isExtension)
{
#if PY_VERSION_HEX >= 0x030b
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
#else
Py_TYPE(*type) = PY_TYPE(FinalizerClass);
#endif
Py_INCREF(PY_TYPE(FinalizerClass));
}

PyObject *module_name = PyModule_GetNameObject(module);

if (module_name != NULL)
{
PyDict_SetItemString((*type)->tp_dict, "__module__", module_name);
Py_DECREF(module_name);
}

PyModule_AddObject(module, name, (PyObject *) *type);
}
}
```



> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629183#comment-17629183
 ] 

Andi Vajda commented on PYLUCENE-66:


Use the JCC in the 9.4.1 release candidate or get the diff for rev 1904960.

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[VOTE] Release PyLucene 9.4.1-rc3

[Andi Vajda]

The PyLucene 9.4.1 (rc3) release tracking the recent release of
Apache Lucene 9.4.1 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.4.1-rc3/

PyLucene 9.4.1 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2, although Python 2 support is now 
untested.


Please vote to release these artifacts as PyLucene 9.4.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.4.1-rc2

[Andi Vajda]

This vote has now failed too as Py_SET_TYPE is not available in Python 3.6.
rc3 is ready.

Sorry for the noise,

Andi..

On Tue, 1 Nov 2022, Andi Vajda wrote:


The PyLucene 9.4.1 (rc2) release tracking the recent release of
Apache Lucene 9.4.1 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.4.1-rc2/

PyLucene 9.4.1 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2, although Python 2 support is now 
untested.


Please vote to release these artifacts as PyLucene 9.4.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.4.1-rc2

[Andi Vajda]

On Tue, 1 Nov 2022, Benjamin Trent wrote:


Andi,

I pulled down the rc-2 and tested in Docker on Ubuntu 18.04.6 LTS (Bionic
Beaver), with Python 3.6.9, I get the following error attempting to build
JCC

jcc3/sources/functions.cpp: In function 'void installType(PyTypeObject**,
PyType_Def*, PyObject*, char*, int)':
jcc3/sources/functions.cpp:1742:13: error: 'Py_SET_TYPE' was not declared
in this scope
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));


Ok, that says that this macro doesn't exist in Python 3.6.
I can add some conditionals around this.
I guess we're now onto rc3...

Andi..


^~~
jcc3/sources/functions.cpp:1742:13: note: suggested alternative:
'__S64_TYPE'
Py_SET_TYPE(*type, PY_TYPE(FinalizerClass));
^~~
__S64_TYPE
error: command 'aarch64-linux-gnu-gcc' failed with exit status 1

I am thinking https://issues.apache.org/jira/browse/PYLUCENE-66 is related.

Thanks!

On Tue, Nov 1, 2022 at 2:13 PM Andi Vajda  wrote:



The PyLucene 9.4.1 (rc2) release tracking the recent release of
Apache Lucene 9.4.1 is ready.

A release candidate is available from:
https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.4.1-rc2/

PyLucene 9.4.1 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2, although Python 2 support is now
untested.

Please vote to release these artifacts as PyLucene 9.4.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[VOTE] Release PyLucene 9.4.1-rc2

[Andi Vajda]

The PyLucene 9.4.1 (rc2) release tracking the recent release of
Apache Lucene 9.4.1 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.4.1-rc2/

PyLucene 9.4.1 is built with JCC 3.13, included in these release artifacts.

JCC 3.13 supports Python 3.3 up to Python 3.11.
PyLucene may also be built with Python 2, although Python 2 support is now 
untested.


Please vote to release these artifacts as PyLucene 9.4.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.4.1

[Andi Vajda]

This vote has failed - we need to release a new version of JCC after all in 
order to support Python 3.11, which came out last week.


Preparing rc2.

Andi..

On Mon, 31 Oct 2022, Andi Vajda wrote:



The PyLucene 9.4.1 (rc1) release tracking the recent release of
Apache Lucene 9.4.1 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.4.1-rc1/

PyLucene 9.4.1 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3, although Python 2 support is
now untested.

Please vote to release these artifacts as PyLucene 9.4.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Comment Edited] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626895#comment-17626895
 ] 

Andi Vajda edited comment on PYLUCENE-66 at 11/1/22 1:12 AM:
-

I switched that line to use Py_SET_TYPE() and that should fix this bug.
I have not yet upgrade to Python 3.11 yet, could you please try this fix and 
see if there are other issues with Python 3.11 ?
Thanks !
(The fix is in rev 1904960)


was (Author: vajda):
I switched that line to use Py_SET_TYPE() and that should fix this bug.
I have not yet upgrade to Python 3.11 yet, could you please try this fix and 
see if there are other issues with Python 3.11 ?
Thanks !
(The fix is in rev 1904960)

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626895#comment-17626895
 ] 

Andi Vajda commented on PYLUCENE-66:


I switched that line to use Py_SET_TYPE() and that should fix this bug.
I have not yet upgrade to Python 3.11 yet, could you please try this fix and 
see if there are other issues with Python 3.11 ?
Thanks !
(The fix is in rev 1904960)

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (PYLUCENE-66) JCC doesn't build with Python 3.11.

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-66.

Resolution: Fixed

fixed in rev 1904960.

> JCC doesn't build with Python 3.11.
> ---
>
> Key: PYLUCENE-66
> URL: https://issues.apache.org/jira/browse/PYLUCENE-66
> Project: PyLucene
>  Issue Type: Bug
> Environment: Python 3.11, PyLucene 9.4.1-rc
>Reporter: A. Coady
>Priority: Major
>
> {{#10 10.86 In file included from /usr/local/include/python3.11/Python.h:44,}}
> {{#10 10.86 from _jcc3/java/lang/Object.h:18,}}
> {{#10 10.86 from jcc3/sources/functions.cpp:23:}}
> {{#10 10.86 jcc3/sources/functions.cpp: In function ‘void 
> installType(PyTypeObject*{*}, PyType_Def{*}, PyObject*, char*, int)’:}}
> {{#10 10.86 /usr/local/include/python3.11/object.h:136:30: error: lvalue 
> required as left operand of assignment}}
> {{#10 10.86 136 | # define Py_TYPE(ob) Py_TYPE(_PyObject_CAST(ob))}}
> {{#10 10.86 | ~{~}{{~}}^{{~}}{~}~}}
> {{#10 10.86 jcc3/sources/functions.cpp:1742:13: note: in expansion of macro 
> ‘Py_TYPE’}}
> {{#10 10.86 1742 | Py_TYPE(*type) = PY_TYPE(FinalizerClass);}}
> {{#10 10.86 | ^~~}}
> {{#10 10.89 error: command '/usr/bin/gcc' failed with exit code 1}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[VOTE] Release PyLucene 9.4.1

[Andi Vajda]

The PyLucene 9.4.1 (rc1) release tracking the recent release of
Apache Lucene 9.4.1 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.4.1-rc1/

PyLucene 9.4.1 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3, although Python 2 support is
now untested.

Please vote to release these artifacts as PyLucene 9.4.1.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: New release of PyLucene?

[Andi Vajda]

On Mon, 31 Oct 2022, Benjamin Trent wrote:


Thank you very much Andi!

Once I wrapped my head around the basics, I found PyLucene
excellent, intuitive, and just like writing in Lucene, but with Python!

It would be marvelous if we could automate the process or document the
steps for building newer versions.


Sadly, the marvelous documentation goes as follows:
  - point PyLucene's Makefile at the version of Lucene you wish to wrap
  - build PyLucene as usual
  - fix the breakages

For example, for Lucene 9.4.1, the only breakage was updating the hppc 
version. Trivial, this time.


Andi..

Re: New release of PyLucene?

[Andi Vajda]

> On Oct 31, 2022, at 07:55, Benjamin Trent  wrote:
> 
> Lucene 9.4.1 was recently released. The last version of PyLucene released
> was 9.1.0. There have been some improvements to Lucene since then. My
> particular concern is around KNN search.
> 
> What is the process to start a new release of PyLucene?

Showing interest, which you just did !
Let me get one going...

Andi..

> 
> 
> Thank you!
> 
> Ben

[jira] [Commented] (PYLUCENE-64) ModuleNotFoundError: No module named 'lucene' when intalling PyLucene

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545615#comment-17545615
 ] 

Andi Vajda commented on PYLUCENE-64:


I believe there is an issue with running 'make test' in PyLucene 8.x. This is 
hopefully solved in PyLucene 9.1.0, which was released on 4/27/22.
To see if your PyLucene install works, you can try these steps in Python:
  >>> import lucene
  >>> lucene.initVM()
  >>> from org.apache.lucene.document import Document

If you need more help, please include the portion of the PyLucene Makefile you 
edited before you ran 'make' and 'make install'.



> ModuleNotFoundError: No module named 'lucene' when intalling PyLucene
> -
>
> Key: PYLUCENE-64
> URL: https://issues.apache.org/jira/browse/PYLUCENE-64
> Project: PyLucene
>  Issue Type: Bug
>Reporter: anis amirouche
>Priority: Major
>
> I'm trying to install Pylucene 8.11.0 on mac os. the jcc is built and 
> installed successfully, but from pylucene folder when running make test i'm 
> encountering the following error : ModuleNotFoundError: No module named 
> 'lucene', please note the make command is successfull.
> please can anyone help me with solving this error. I don't even understand 
> what i'm doing wrong, it's like lucene is not installed, and i'm having this 
> error with all the files of pylucene. 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Andi Vajda]

-1 (PMC, but not a veto)

Why ? As stated earlier, I'm not confortable with depending on GitHub for 
governance. As long as Lucene is an "Apache" project, I'd like Apache 
governance to determine who may or may not participate, not GitHub. I'd like 
Apache to determine what is and is not "acceptable behavior" from project 
participants.


That being said, the reasons for migrating off of Jira are all sound and, as 
an alternative, I propose that we consider moving to an Apache-hosted 
instance of GitLab. We'd still get all the benefits of migrating off of Jira 
but also the benefits of Apache running our infrastructure and setting our 
governance. Feature-wise, GitHub and GitLab are very similar but GitLab 
offers the possibility of self-hosting our instance.


Andi..

On Tue, 31 May 2022, Tomoko Uchida wrote:


Hi everyone!

As we had previous discussion thread [1], I propose migration to GitHub
issue from Jira.
It'd be technically possible (see [2] for details) and I think it'd be good
for the project - not only for welcoming new developers who are not
familiar with Jira, but also for improving the experiences of long-term
committers/contributors by consolidating the conversation platform.

You can see a short summary of the discussion, some stats on current Jira
issues, and a draft migration plan in [2].
Please review [2] if you haven't seen it and vote for this proposal.

The vote will be open until 2022-06-06 16:00 UTC.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1

*IMPORTANT NOTE*
I set a local protocol for this vote.
There are 95 committers on this project [3] - the vote will be effective if
it successfully gains more than 15% of voters (>= 15) from committers
(including PMC members). This means, that although only PMC member votes
are counted for the final result, the votes from all committers are
important to make the vote result effective.

If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand the
term to 2022-06-13 16:00 UTC. If this fails to get sufficient voters after
the expanded time limit, I'll cancel this vote regardless of the result.
But why do I set such an extra bar? My fear is that if such things are
decided by the opinions of a few members, the result shouldn't yield a good
outcome for the future. It isn't my goal to just pass the vote [4].

[1] https://lists.apache.org/thread/78wj0vll73sct065m5jjm4z8gqb5yffk
[2] https://issues.apache.org/jira/browse/LUCENE-10557
[3] https://projects.apache.org/committee.html?lucene
[4] I'm sorry for being overly cautious, but I have never met in person or
virtually any of the committers (with a very few exceptions), therefore
cannot assess if the vote result is reliable or not unless there is certain
explicit feedback.

Tomoko



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

On Mon, 9 May 2022, Gus Heck wrote:


It's been a long time since I've tried to look around in the issue tracker
space. Are there 3rd options that might be easier to use, under our direct
control and perhaps easier to influence. I've not looked at it, what do we
know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would
have a nice ASF using it's own software angle...


As I suggested earlier, an Apache hosted version of GitLab might work. I'm 
not sure how different it is from GitHub from the point of view of issue 
tracking but it checks the better control box. The ASF has been hosting all 
our infra for decades, I'm sure they're capable of hosting a GitLab install.
If the Videolan [1] (VLC project) or the ISC [2] (Bind project) can do it, 
so can Apache.


Andi..

[1] https://code.videolan.org/videolan/vlc
[2] https://gitlab.isc.org/isc-projects/bind9


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

On Thu, 5 May 2022, Jan Høydahl wrote:

ASF has officially blessed use of github issues as alternative to Jira. 
They are not going to setup a private GitLab or tool X. While GitLab is 
nice, I don't think the main intention with the proposal was to inroduce 
yet another platform where contributors need to register an account and 
learn the UI :)


That's precisely the crux of the disagreement: I want to be able to register 
an account at Apache and *not* GitHub and still be able to contribute. So 
yes, registering accounts in various places makes one's participation in 
them more resilient to auto-banning-without-due-process-nor-recourse.


As for learning the new UI, GitLab and GitHub are very alike.

Is the original Jira -> GitHub move just a change of defaults or are we, 
once moved to GitHub, not letting people use Jira at all anymore ?


Andi..




GitHub issues versions are tracked in "Milestones" - 
https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones 


See example from solr-operator. These issues or PRs were released in v0.5.1: 
https://github.com/apache/solr-operator/milestone/8?closed=1 

Labels are also very flexibl.

Jan


5. mai 2022 kl. 22:18 skrev David Smiley :

Is anyone familiar with using GitHub (or maybe GitLab I suppose) for tracking metadata 
about the issue -- something JIRA excels at?  For example the version of our project that 
a given PR is released in -- aka the JIRA "Fix Version"?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley 


On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida mailto:tomoko.uchida.1...@gmail.com>> wrote:
Hello everyone!

Recently, we relaxed the requirement for creating a Jira issue when opening a pull 
request (LUCENE-10545 ).

As the next and bigger (perhaps ambitious) step, I opened a rough proposal for 
migration to GitHub issue from Jira.
https://issues.apache.org/jira/browse/LUCENE-10557 


According to the INFRA issue for the RocketMQ project (Michael McCandless gave 
the pointer in a comment on the issue; thanks!), a PMC agreement or Vote result 
is needed for the decision.
https://issues.apache.org/jira/browse/INFRA-15702 


Eventually, we'd need a formal vote, but before that, I'd like to hear general 
opinions/thoughts (or feelings) on this topic from developers.

In brief, I think it'd be technically possible and also be good for the project 
- not only for welcoming new developers who are not familiar with Jira, but 
also for improving the experiences of long-term contributors by consolidating 
the conversation platform.
It'll need some administrative work though, I'm willing to work for it if we 
reach an agreement.

Please note that:
* This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we 
don't aim to reach a conclusion in this thread.
* Let's not discuss "how to migrate existing Jira issues" for now. Once we 
decide the migration will be good for us, then we can try to figure out a reasonable 
solution for technical/administrative matters.

I may be too optimistic about it; but - a bit of stupidness will be needed to 
start such a move, and I'm serious about this proposal :)

Thanks and regards,
Tomoko




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

> On May 5, 2022, at 08:49, Tomoko Uchida  wrote:
> 
> 
> It's really interesting to me to hear how others feel comfortable (or 
> discomfortable) with the tools!
> 
> I myself am not an expert of either JIra or GitHub, and actually have no 
> feelings on which tool is better. 
> The only motivation for my proposal was, "consolidate the conversation 
> platform and reduce the context switch between two platforms".
> 
> However, I don't want to narrow the theme of conversation too early, so 
> please freely express your thoughts. 

My main gripe with Jira is that I can't respond to Jira comments via email. I 
have to always use their interface.

Andi..

> 
> Hi Ishan,
> 
> > I'm generally opposed to this idea because GitHub has been known to take 
> > political decisions to cut off access to developers just because of their 
> > nationality/region etc.
> 
> Sorry I haven't heard of such matters for GitHub. Can you please present the 
> reference?
> 
> Tomoko
> 
> 
> 2022年5月6日(金) 0:41 Ishan Chattopadhyaya :
>> (Repeating in public what I mentioned in private)
>> 
>> 
>> I'm generally opposed to this idea because GitHub has been known to take 
>> political decisions to cut off access to developers just because of their 
>> nationality/region etc. As a community, we should stay politically neutral 
>> and not rely on GitHub to decide on our behalf who to exclude from our 
>> community.
>> 
>>> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl,  wrote:
>>> Given how JIRA has become a monster of a product with different markup 
>>> syntax for each version, and bugs everywhere (does not even work on 
>>> mobile), I'm no longer the JIRA fan I once was.
>>> 
>>> In Solr we already use github issues for the Solr-Operator sub project 
>>> https://github.com/apache/solr-operator/issues and I believe it has worked 
>>> well. Of course excellent integration with PRs :)
>>> In earlier discussions on this topic, the idea has been shot down with the 
>>> argument of split bug history and migration challenges. But I think you are 
>>> wise to delay the HOW discussion for now.
>>> This discussion should also not be about politics. Some may be opposed to 
>>> Microsoft and GitHub, but as long as the ASF has officially blessed github 
>>> as an official option, i'ts not a very constructive discussion.
>>> The most important decision point on my part is perception by new / young 
>>> users. Look at OpenOffice, they have remained on Bugzilla - are you 
>>> compelled to contribute? :)
>>> 
>>> Jan
>>> 
 5. mai 2022 kl. 04:23 skrev Tomoko Uchida :
 
 Hello everyone!
 
 Recently, we relaxed the requirement for creating a Jira issue when 
 opening a pull request (LUCENE-10545).
 
 As the next and bigger (perhaps ambitious) step, I opened a rough proposal 
 for migration to GitHub issue from Jira.
 https://issues.apache.org/jira/browse/LUCENE-10557
 
 According to the INFRA issue for the RocketMQ project (Michael McCandless 
 gave the pointer in a comment on the issue; thanks!), a PMC agreement or 
 Vote result is needed for the decision.
 https://issues.apache.org/jira/browse/INFRA-15702
 
 Eventually, we'd need a formal vote, but before that, I'd like to hear 
 general opinions/thoughts (or feelings) on this topic from developers.
 
 In brief, I think it'd be technically possible and also be good for the 
 project - not only for welcoming new developers who are not familiar with 
 Jira, but also for improving the experiences of long-term contributors by 
 consolidating the conversation platform. 
 It'll need some administrative work though, I'm willing to work for it if 
 we reach an agreement.
 
 Please note that:
 * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but 
 we don't aim to reach a conclusion in this thread.
 * Let's not discuss "how to migrate existing Jira issues" for now. Once we 
 decide the migration will be good for us, then we can try to figure out a 
 reasonable solution for technical/administrative matters. 
 
 I may be too optimistic about it; but - a bit of stupidness will be needed 
 to start such a move, and I'm serious about this proposal :)
 
 Thanks and regards,
 Tomoko
>>> 

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Andi Vajda]

> On May 5, 2022, at 08:41, Ishan Chattopadhyaya  
> wrote:
> 
> 
> (Repeating in public what I mentioned in private)
> 
> 
> I'm generally opposed to this idea because GitHub has been known to take 
> political decisions to cut off access to developers just because of their 
> nationality/region etc. As a community, we should stay politically neutral 
> and not rely on GitHub to decide on our behalf who to exclude from our 
> community.

Agreed. My main issue with hosted services like GitHub and others like it is 
that as they there is no due process, very little recourse, when some AI or 
other automated process gets you banned. Again, this is an issue for all such 
services and it's worse the bigger they are. It's also an "all eggs in the same 
basket" problem.
Thus, I prefer to depend on Apache than on GitHub.
If we want to move off of Jira, I think doing so on a self (Apache)-hosted 
instance of GitLab would be a lot better and offer the same enticing eye candy 
and issue/PR integration as GitHub.

Andi..


> 
>> On Thu, 5 May, 2022, 8:45 pm Jan Høydahl,  wrote:
>> Given how JIRA has become a monster of a product with different markup 
>> syntax for each version, and bugs everywhere (does not even work on mobile), 
>> I'm no longer the JIRA fan I once was.
>> 
>> In Solr we already use github issues for the Solr-Operator sub project 
>> https://github.com/apache/solr-operator/issues and I believe it has worked 
>> well. Of course excellent integration with PRs :)
>> In earlier discussions on this topic, the idea has been shot down with the 
>> argument of split bug history and migration challenges. But I think you are 
>> wise to delay the HOW discussion for now.
>> This discussion should also not be about politics. Some may be opposed to 
>> Microsoft and GitHub, but as long as the ASF has officially blessed github 
>> as an official option, i'ts not a very constructive discussion.
>> The most important decision point on my part is perception by new / young 
>> users. Look at OpenOffice, they have remained on Bugzilla - are you 
>> compelled to contribute? :)
>> 
>> Jan
>> 
>>> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida :
>>> 
>>> Hello everyone!
>>> 
>>> Recently, we relaxed the requirement for creating a Jira issue when opening 
>>> a pull request (LUCENE-10545).
>>> 
>>> As the next and bigger (perhaps ambitious) step, I opened a rough proposal 
>>> for migration to GitHub issue from Jira.
>>> https://issues.apache.org/jira/browse/LUCENE-10557
>>> 
>>> According to the INFRA issue for the RocketMQ project (Michael McCandless 
>>> gave the pointer in a comment on the issue; thanks!), a PMC agreement or 
>>> Vote result is needed for the decision.
>>> https://issues.apache.org/jira/browse/INFRA-15702
>>> 
>>> Eventually, we'd need a formal vote, but before that, I'd like to hear 
>>> general opinions/thoughts (or feelings) on this topic from developers.
>>> 
>>> In brief, I think it'd be technically possible and also be good for the 
>>> project - not only for welcoming new developers who are not familiar with 
>>> Jira, but also for improving the experiences of long-term contributors by 
>>> consolidating the conversation platform. 
>>> It'll need some administrative work though, I'm willing to work for it if 
>>> we reach an agreement.
>>> 
>>> Please note that:
>>> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we 
>>> don't aim to reach a conclusion in this thread.
>>> * Let's not discuss "how to migrate existing Jira issues" for now. Once we 
>>> decide the migration will be good for us, then we can try to figure out a 
>>> reasonable solution for technical/administrative matters. 
>>> 
>>> I may be too optimistic about it; but - a bit of stupidness will be needed 
>>> to start such a move, and I'm serious about this proposal :)
>>> 
>>> Thanks and regards,
>>> Tomoko
>> 

[jira] [Commented] (PYLUCENE-63) can not install pylucene on linux with proxy

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529472#comment-17529472
 ] 

Andi Vajda commented on PYLUCENE-63:


The first 'make print-GENERATE' shows that you didn't follow the instructions 
at the top of the Makefile. You must uncomment one of the example groups so 
that PREFIX_PYTHON, PYTHON, JCC and NUM_FILES are set. And they must be set 
correctly for your environment.
You then did this, apparently, and your next print-GENERATE is making more 
sense (!).

The next issue then is that you didn't rebuild JCC (it shows you using version 
3.10 but PyLucene 9.1.0 comes with 3.12) and the earlier JCC build you made was 
built with an incompatible version of Java. Please rebuild JCC so that you are 
using version 3.12.

The last issue is that your java installation's layout (in particular its paths 
to libraries libjava and libjvm) is not covered in JCC's setup.py. This is a 
known issue, there are just so many different layouts that it's difficult to 
guess the correct one. You need to edit jcc's setup.py at line 172,173,174 and 
set the values for the -L flags to match your installation. I suspect that you 
don't need the final amd64 parts in there, ie, change -L%(linux)s/jre/lib/amd64 
into -L%(linux)s/jre/lib, change -L%(linux)s/jre/lib/amd64/server to 
-L%(linux)s/jre/lib/server and 
'-Wl,-rpath=%(linux)s/jre/lib/amd64:%(linux)s/jre/lib/amd64/server to 
'-Wl,-rpath=%(linux)s/jre/lib:%(linux)s/jre/lib/server.

Last but not least, you seem to be using python 2.7. It's still supported by 
PyLucene and JCC but not by the Python people anymore and it is not going to be 
supported by PyLucene and JCC much longer. I strongly recommend you install 
python3. Python 2.7 has been dead and deprecated for years now. If you are just 
getting started with Python now, please start with python 3.

And finally, this entire conversation should be had on the 
pylucene-dev@lucene.apache.org mailing list instead of buried in JIRA. This 
issue is not a bug.

> can not install pylucene on linux  with proxy
> -
>
> Key: PYLUCENE-63
> URL: https://issues.apache.org/jira/browse/PYLUCENE-63
> Project: PyLucene
>  Issue Type: Bug
> Environment: ubuntu 2020.4
>Reporter: lisa.shi
>Priority: Major
>
> i try to install pyylucene on linux  with proxy. i have already set 
> http_proxy on linux . i  have change Makefile .
> from 
> cd $(LUCENE); ($(ANT) ivy-availability-check || $(ANT) ivy-bootstrap )
> to
> cd $(LUCENE); ($(ANT) ivy-availability-check -autoproxy|| $(ANT) 
> ivy-bootstrap -autoproxy)
> then i can get ivy-2.4.0.jar in  ~/.ant/lib/
> when i try to make pyluence. i meet a bug.
>  
>  
> ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .pom
> [ivy:cachepath]           – artifact org.codehaus.groovy#groovy-all;2.4  
> .17!groovy-all.jar:
> [ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .jar
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 ::          UNRESOLVED DEPENDENCIES           
> ::
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 :: org.codehaus.groovy#groovy-all;2.4.17  : 
> not found
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]  ERRORS
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.pom (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.pom (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.jar (java.net.ConnectException: Connection timed out (  
> Connection timed out))
>

[jira] [Commented] (PYLUCENE-63) can not install pylucene on linux with proxy

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529212#comment-17529212
 ] 

Andi Vajda commented on PYLUCENE-63:


What does 'make print-GENERATE' return for you ?
Also, please include the values you uncommmented in Makefile for:
  PREFIX_PYTHON, PYTHON, JCC, NUM_FILES


> can not install pylucene on linux  with proxy
> -
>
> Key: PYLUCENE-63
> URL: https://issues.apache.org/jira/browse/PYLUCENE-63
> Project: PyLucene
>  Issue Type: Bug
> Environment: ubuntu 2020.4
>Reporter: lisa.shi
>Priority: Major
>
> i try to install pyylucene on linux  with proxy. i have already set 
> http_proxy on linux . i  have change Makefile .
> from 
> cd $(LUCENE); ($(ANT) ivy-availability-check || $(ANT) ivy-bootstrap )
> to
> cd $(LUCENE); ($(ANT) ivy-availability-check -autoproxy|| $(ANT) 
> ivy-bootstrap -autoproxy)
> then i can get ivy-2.4.0.jar in  ~/.ant/lib/
> when i try to make pyluence. i meet a bug.
>  
>  
> ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .pom
> [ivy:cachepath]           – artifact org.codehaus.groovy#groovy-all;2.4  
> .17!groovy-all.jar:
> [ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .jar
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 ::          UNRESOLVED DEPENDENCIES           
> ::
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 :: org.codehaus.groovy#groovy-all;2.4.17  : 
> not found
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]  ERRORS
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.pom (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.pom (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.jar (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.pom (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.jar (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]
> [ivy:cachepath] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> BUILD FAILED
>  
>  
> how can i fix this bug?
> i am sure the file ( 
> [https://repo1.maven.o|https://repo1.maven.o/]rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar)
>  is not exist



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (PYLUCENE-63) can not install pylucene on linux with proxy

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-63.

Resolution: Information Provided

I cannot help you with proxy issues and this bug is obsolete by now as Lucene 
is now at version 9.1.0 and is no longer using Ant nor Ivy but switched its 
build to Gradle.
Just 10 minutes ago, I released [PyLucene 
9.1.0|https://lucene.apache.org/pylucene/index.html] which also switched to 
using Gradle for building the Lucene part. If you have issues with building the 
Lucene part of PyLucene with Gradle, please contact the Lucene project at 
java-u...@lucene.apache.org.
Thank you !

> can not install pylucene on linux  with proxy
> -
>
> Key: PYLUCENE-63
> URL: https://issues.apache.org/jira/browse/PYLUCENE-63
> Project: PyLucene
>  Issue Type: Bug
> Environment: ubuntu 2020.4
>Reporter: lisa.shi
>Priority: Major
>
> i try to install pyylucene on linux  with proxy. i have already set 
> http_proxy on linux . i  have change Makefile .
> from 
> cd $(LUCENE); ($(ANT) ivy-availability-check || $(ANT) ivy-bootstrap )
> to
> cd $(LUCENE); ($(ANT) ivy-availability-check -autoproxy|| $(ANT) 
> ivy-bootstrap -autoproxy)
> then i can get ivy-2.4.0.jar in  ~/.ant/lib/
> when i try to make pyluence. i meet a bug.
>  
>  
> ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .pom
> [ivy:cachepath]           – artifact org.codehaus.groovy#groovy-all;2.4  
> .17!groovy-all.jar:
> [ivy:cachepath]           [https://repository.cloudera.com/artifactory/li]  
> bs-release-local/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17  .jar
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 ::          UNRESOLVED DEPENDENCIES           
> ::
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]                 :: org.codehaus.groovy#groovy-all;2.4.17  : 
> not found
> [ivy:cachepath]                   
> ::
> [ivy:cachepath]  ERRORS
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.pom (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repo1.maven.o|https://repo1.maven.o/]  
> rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar (j  
> ava.net.ConnectException: Connection timed out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.pom (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://oss.sonatype|https://oss.sonatype/].  
> org/content/repositories/releases/org/codehaus/groovy/groovy-all/2.4.17/  
> groovy-all-2.4.17.jar (java.net.ConnectException: Connection timed out (  
> Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.pom (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]         Server access error at url 
> [https://repository.cl|https://repository.cl/]  
> oudera.com/artifactory/libs-release-local/org/codehaus/groovy/groovy-all  
> /2.4.17/groovy-all-2.4.17.jar (java.net.ConnectException: Connection tim  ed 
> out (Connection timed out))
> [ivy:cachepath]
> [ivy:cachepath] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> BUILD FAILED
>  
>  
> how can i fix this bug?
> i am sure the file ( 
> [https://repo1.maven.o|https://repo1.maven.o/]rg/maven2/org/codehaus/groovy/groovy-all/2.4.17/groovy-all-2.4.17.jar)
>  is not exist



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: [VOTE] Release PyLucene 9.1.0 (rc4)

[Andi Vajda]

This vote has passed.
Thank you all who voted !

Andi..

On Fri, 22 Apr 2022, Andi Vajda wrote:



The PyLucene 9.1.0 (rc4) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc4/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.1.0 (rc4)

[Andi Vajda]

 Hi Mike,

On Tue, 26 Apr 2022, Andi Vajda wrote:


I have not yet tested PyLucene and JCC with python 3.10.
It could be that the heuristics for modern setuptools need to be updated 
again...


I don't think it's worth respinning but I need to have python 3.10 and this 
setuptools stuff resolved for the next release.


I installed python 3.10.4 on macos from sources.
It came with setuptools 58.1.0.

I was able to build jcc shared without forcing with_modern_setuptools.
I then ran pip install --upgrade setuptools and got version 62.1.0.
I was still able to build jcc shared without forcing with_modern_setuptools.

What version of setuptools do you have installed ?

Andi..

Re: [VOTE] Release PyLucene 9.1.0 (rc4)

[Andi Vajda]

 Hi Mike,

Thank you for your vote.
Replies inline...

On Tue, 26 Apr 2022, Michael McCandless wrote:


+1 to release.

I ran my usual smoke test, indexing first 100K Wikipedia docs, running a
couple queries, force merging down to one segment and running them again.

I discovered in this process that IndexWriter.getReader() had been removed
and tracked down the change that did that (it's good, thanks Dawid!) :)

I did hit one wrinkle during installation -- JCC was not built with a
shared lib by default, and poking around in setup.py, I found that it had
detected with_modern_setuptools = False, which was odd since I'm using
Python 3.10.2 (and JDK 17 on Arch Linux).  I tried "pip3 install
setuptools" but it was already up to date.  Then I edited setup.py and
"hardwired" the with_modern_setuptools to True, and then everything
installed fine.  Maybe I did something silly wrong in editing setup.py /
Makefile, so I don't think this has to block release ...


I have not yet tested PyLucene and JCC with python 3.10.
It could be that the heuristics for modern setuptools need to be updated 
again...


I don't think it's worth respinning but I need to have python 3.10 and this 
setuptools stuff resolved for the next release.


Andi..



Mike McCandless

http://blog.mikemccandless.com


On Mon, Apr 25, 2022 at 8:20 AM Nelia Vb  wrote:


+1


On 22 Apr 2022, at 23:51, Andi Vajda  wrote:


The PyLucene 9.1.0 (rc4) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc4/

PyLucene 9.1.0 is built with JCC 3.12, included in these release

artifacts.


JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python

2.3+).

PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[VOTE] Release PyLucene 9.1.0 (rc4)

[Andi Vajda]

The PyLucene 9.1.0 (rc4) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc4/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.1.0 (rc3)

[Andi Vajda]

This vote has now also failed.
There is still an issue with the PyLucene gradle setup

Andi..

On Wed, 20 Apr 2022, Andi Vajda wrote:



The PyLucene 9.1.0 (rc3) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc3/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[VOTE] Release PyLucene 9.1.0 (rc3)

[Andi Vajda]

The PyLucene 9.1.0 (rc3) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc3/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.1.0

[Andi Vajda]

On Wed, 20 Apr 2022, Andi Vajda wrote:

Ok, so the layout has changed with temurin I guess. This was also the case on 
Mac. I need to add yet another entry into LFLAGS for linux/temurin

in setup.py that reflects this new layout.


So it seems to be some sort of expected-packaging problem?


I need to debug this by installing temurin into a linux VM of mine.
To be continued...


I created a brand new Debian 11.3 virtual machine and set it up for PyLucene 
development with the Temurin 17 JDK. I had to add a new linux/temurin entry 
in LFLAGS since the layout of that JDK is different from the others.


Then I changed the JDK['linux'] in jcc's setup.py to the Temurin java home 
as it looked on my install: /usr/lib/jvm/temurin-17-jdk-amd64
It may be different on your system. You edit in yours or override it via the 
JCC_JDK env variable.


Then building jcc with:
  $ python setup.py build install
just worked (tm)

For PyLucene, I also refreshed the first Linux config to be for Temurin JDK.
Uncomment that one and fix it to reflect your environment.
Then building pylucene with:
  $ make all test
just worked (tm).

I'm preparing an rc3 now...

Andi..

Re: [VOTE] Release PyLucene 9.1.0 (rc2)

[Andi Vajda]

This vote has now failed too, linux support needs to be improved...

Andi..

> On Apr 19, 2022, at 17:29, Andi Vajda  wrote:
> 
> 
> The PyLucene 9.1.0 (rc2) release tracking last month's release of
> Apache Lucene 9.1.0 is ready.
> 
> A release candidate is available from:
>   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc2/
> 
> PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.
> 
> JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
> PyLucene may be built with Python 2 or Python 3.
> 
> Please vote to release these artifacts as PyLucene 9.1.0.
> Anyone interested in this release can and should vote !
> 
> Thanks !
> 
> Andi..
> 
> ps: the KEYS file for PyLucene release signing is at:
> https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
> https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS
> 
> pps: here is my +1

Re: [VOTE] Release PyLucene 9.1.0

[Andi Vajda]

 Hi Dawid,

On Wed, 20 Apr 2022, Dawid Weiss wrote:


If you tell me what OS you are on and what the error actually is, I can
help you a bit better. But assuming you're on a Mac, you do not need to 
export



I'm actually on Windows but I tried to compile everything on Linux - an
older Ubuntu with Java 17 installed. Here is what I see:


echo $JAVA_HOME

/[...]/jvms/jdk17


java -version

openjdk version "17" 2021-09-14
OpenJDK Runtime Environment Temurin-17+35 (build 17+35)
OpenJDK 64-Bit Server VM Temurin-17+35 (build 17+35, mixed mode, sharing)


cd jcc
python3 setup.py build install

Traceback (most recent call last):
 File "setup.py", line 100, in 
   ''' %(JDK[platform]))
RuntimeError:

Java JDK directory '/usr/lib/jvm/java-8-oracle' does not exist.


Yeah, on Linux, there is no support implemented in JCC for finding the 
proper JAVA_HOME so the hardcoded value in jcc's setup.py is old and wrong

and must be overriden via the JCC_JDK variable (or edited in).


Please set the environment variable JCC_JDK to the correct location before
running setup.py.

When I set JCC_JDK:


export JCC_JDK=$JAVA_HOME
python3 setup.py build install

[lots of messages]
x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-Bsymbolic-functions -Wl,-z,relro
-g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.6/jcc3/sources/jcc.o
build/temp.linux-x86_64-3.6/jcc3/sources/JCCEnv.o -o
build/lib.linux-x86_64-3.6/libjcc3.so -L/[...]/jvms/jdk17/jre/lib/amd64
-ljava -L/ [...]/jvms/jdk17/jre/lib/amd64/server -ljvm -Wl,-rpath=/
[...]/jvms/jdk17/jre/lib/amd64:/ [...]/jvms/jdk17/jre/lib/amd64/server
-Wl,-S -lpython3.6m

/usr/bin/ld: cannot find -ljava
/usr/bin/ld: cannot find -ljvm
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-g++' failed with exit status 1

When you look at the compilation line, Java-relative paths are wrong as
it's a JDK installation and it has lib/ and include/ directly underneath
(not under 'jre/lib/amd64', for example).


Ok, so the layout has changed with temurin I guess. This was also the case 
on Mac. I need to add yet another entry into LFLAGS for linux/temurin

in setup.py that reflects this new layout.


So it seems to be some sort of expected-packaging problem?


I need to debug this by installing temurin into a linux VM of mine.
To be continued...

Andi..

[VOTE] Release PyLucene 9.1.0 (rc2)

[Andi Vajda]

The PyLucene 9.1.0 (rc2) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc2/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.1.0

[Andi Vajda]

This vote has failed as the release artifacts were found to contain 
unnecessary cruft.


Thank you Dawid for reporting the issue.
I'm calling for an rc2 vote in the next message.

Andi..

On Sun, 17 Apr 2022, Andi Vajda wrote:



The PyLucene 9.1.0 (rc1) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc1/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

Re: [VOTE] Release PyLucene 9.1.0

[Andi Vajda]

 Hi Dawid,

Thank you for checking the rc out !
More replies inline.

On Tue, 19 Apr 2022, Dawid Weiss wrote:


I downloaded the release - these files and folders should be probably
excluded from the distribution as it's gradle's binary
throw-away caches and generated stuff:

pylucene-9.1.0/lucene-java-9.1.0/.gradle
pylucene-9.1.0/lucene-java-9.1.0/gradle.properties

Perhaps you should use "git clean -xfd ." on Lucene's checkout prior
to assembling the distribution?


I'm now excluding all .[a-z]* files as well as gradle.properties.
And I'm respinning an rc2 for this change.


Also, the installation instructions seem a bit outdated (Java version, etc.):
https://lucene.apache.org/pylucene/install.html

I tried compiling everything from scratch by exporting JAVA_HOME and
JCC_JDK but failed. :(  Any hints as to what I may be doing wrong?


The instructions are very outdated indeed (!)

If you tell me what OS you are on and what the error actually is, I can help 
you a bit better. But assuming you're on a Mac, you do not need to export 
JAVA_HOME, but you can, it overrides what jcc is trying to do without it 
being set.

The $ /usr/libexec/java_home command works, it returns this
  /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
for me, which is correct.
If you do *not* set JAVA_HOME, jcc will try to figure it out for you, and 
report what it found (or not).


For me, on Mac, the build instructions are as simple as this:
I have python 3 in a virtual environment in my pylucene directory:
  $ cd ~/apache/pylucene/jcc
  $ ../_install3/bin/python setup.py build install
  $ cd ..
edit Makefile to uncommment/edit the configuration that corresponds to
your setup
  $ make all test

Please, let me know how it goes !

Andi..



Dawid

On Sun, Apr 17, 2022 at 9:48 PM Andi Vajda  wrote:



The PyLucene 9.1.0 (rc1) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc1/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[VOTE] Release PyLucene 9.1.0

[Andi Vajda]

The PyLucene 9.1.0 (rc1) release tracking last month's release of
Apache Lucene 9.1.0 is ready.

A release candidate is available from:
   https://dist.apache.org/repos/dist/dev/lucene/pylucene/9.1.0-rc1/

PyLucene 9.1.0 is built with JCC 3.12, included in these release artifacts.

JCC 3.12 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 9.1.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Resolved] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda resolved PYLUCENE-62.

Resolution: Fixed

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, 
> fixes_with_inclusion _of_windows_module.patch, jvm_dll.diff, small_fixes.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523433#comment-17523433
 ] 

Andi Vajda commented on PYLUCENE-62:


Thank you for having verified the changes again.
The 'import jcc' case, as you say, is not very useful but can be made to work 
by calling os.add_dll_directory(jvm_dll_path) manually first. If one is import 
the jcc package this way, they must know what they're up to.
I can't connect the %PREFIX%\lib\site-packages\jcc3\jcc3.lib issue to code in 
jcc other than the extra_link_args being set in python.py around line 1843. I 
don't see, at first glance, where %prefix% would be coming from.
I think this bug can now be marked fixed, please reopen if you think it needs 
more work.
Thank you again for all your work on this !

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, 
> fixes_with_inclusion _of_windows_module.patch, jvm_dll.diff, small_fixes.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523248#comment-17523248
 ] 

Andi Vajda commented on PYLUCENE-62:


Thank you for the fixes and explanations. I think I integrated your changes and 
even simplified things a bit more in python.py, now that we're including 
windows.py when --find-jvm-dll is set.
I committed the changes to HEAD. Please, try this out again by setting 
--find-jvm-dll server and let me know if it all works. Thank you !

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, 
> fixes_with_inclusion _of_windows_module.patch, jvm_dll.diff, small_fixes.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522433#comment-17522433
 ] 

Andi Vajda commented on PYLUCENE-62:


Does it work as expected if you pass --find-jvm-dll server to your command line 
?

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521968#comment-17521968
 ] 

Andi Vajda commented on PYLUCENE-62:


Hi Petrus, this issue seems to have stalled. 
Is it actually solved by the latest jvm_dll.diff patch attached here ?
I'm preparing to release PyLucene 9.1.0 and it'd be nice to know if it still 
works on Windows !

(thanks)

Andi..

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495042#comment-17495042
 ] 

Andi Vajda commented on PYLUCENE-62:


I'd like which kind of jvm.dll is used to not be random with regards to client 
or server kind. But if you prefer both to be searchable as well, we can add 
support for a "both" --find_jvm_dll value, that searches "client", then 
"server" (or the opposite, but again, not random)The default should remain 
"client" since that is what it's been doing for years. Also, it would be good 
to emit a log statement of some sort that says what jvm.dll (its full path) was 
found and added to the DLL path.
Bullet 2: I can't bet that people wouldn't copy source code around. It's also 
easier to debug if the same code is emitted everywhere, regardless of platform, 
using conditional code as necessary.
The stuff after SHARED is unchanged, your patch didn't touch it, nor did my 
changes. I'm wondering what to do about it, though, as it is also messing with 
PATH. Are you using --shared mode ?
About "it doesn't work": I can't debug this as I don't have access to Windows. 
Here, on mac, the following works fine, of course: python -c "import jcc; 
print(jcc.__file__)". Could you please take the current patch and "make it 
work" or, if you'd like my help with debugging it, tell me more details about 
what doesn't actually work ? In particular, please, add print statements in the 
__init__.py  and windows.py files as to what is going on until it eventually 
fails and send me the output. Thanks !

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492230#comment-17492230
 ] 

Andi Vajda commented on PYLUCENE-62:


I also not sure what to about the code in __init__.py, after line 28, in the 
SHARED case ?
Should the eggpath be added via os.add_dll_directory() as well ?
Are you using shared mode ?


> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492229#comment-17492229
 ] 

Andi Vajda commented on PYLUCENE-62:


I took a look at your patch and attached a version that should be less 
intrusive and work, hopefully, too:
  - you do not need to add windows.py to modules, it is already included and 
installed
  - you do need to keep code conditional to windows, you can't assume people 
are not
going to carry code around between machines
  - in windows.py, I renamed get_jvm_dll_directory() to 
get_jvm_dll_directory_from_registry()
   and otherwise kept it unchanged
  - in windows.py, I added get_jvm_dll_directory_from_env() based on your code.
  - in windows.py, I also changed add_jvm_dll_directory_to_path() to do the 
right thing, like
you did
  - I changed the --find-jvm-dll command line flag from a boolean to a string 
that must be one
of "client" or "server" and made it default to "client" for python >= 3.8, 
None otherwise.
Please, try the attached patch out by passing it --find-jvm-dll client (or 
server), I have no access to Windows, so I could not try it out myself. I 
verified that it didn't break on Mac.
Thank you !


> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

 [ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andi Vajda updated PYLUCENE-62:
---
Attachment: jvm_dll.diff

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win-1.patch, add_dll_win.patch, jvm_dll.diff
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491669#comment-17491669
 ] 

Andi Vajda commented on PYLUCENE-62:


As is, --find-jvm-dll shouldn't solve the issue because it modifies PATH and 
doesn't use the new os.add_dll_directory() function. 
If, on the other hand, you modify windows.py's add_jvm_dll_directory_to_path() 
to call os.add_dll_directory() instead of messing with Path, does 
--find-jvm-dll then solve the problem ? 
I have no access to Windows so I can't test any fix myself.
Currently, windows.py's get_jvm_dll_directory() does not look on JAVA_HOME. I 
think that it's reasonable that it should do so, as well as looking in the 
Windows registry like it does already. Maybe it should look at JAVA_HOME first, 
then continue looking in the registry if nothing is found ? Your JAVA_HOME 
traversal code should be added to get_jvm_dll_directory() so that all this 
logic is in one place.

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491471#comment-17491471
 ] 

Andi Vajda edited comment on PYLUCENE-62 at 2/12/22, 11:34 PM:
---

It looks like finding the jvm.dll is an old problem on Windows and python 3.8 
just made it a bit worse. If you look in jcc3/__init__.py, which you modified 
in this patch, you can see that something similar is done when the 
--find-jvm-dll command line flag is set.
The code in jcc3/windows.py has something a bit more involved than just relying 
on JAVA_HOME to locate this DLL. I think you should update the 
add_jvm_dll_directory_to_path() to use the new python 3.8 add_dll_directory() 
function instead of its current messing with the Path environment variable. If 
you think of making --find-jvm-dll the default on Windows/python3.8, then the 
add_jvm_dll_directory_to_path() function in windows.py should verify that 
jvm.dll isn't already findable, before adding another DLL path if necessary.
Same issue with the changes in jcc3/python.py: you should not depend on 
JAVA_HOME but share the same logic in jcc3/windows.py (assuming that logic is 
still correct, of course).
In other words, does --find-jvm-dll work for you ? (without your patch).


was (Author: vajda):
It looks like finding the jvm.dll is an old problem on Windows and python 3.8 
just made it a bit worse. If you look in jcc3/__init__.py, which you modified 
in this patch, you can see that something similar is done when the 
--find-jvm-dll command line flag is set.
The code in jcc3/windows.py has something a bit more involved than just relying 
on JAVA_HOME to locale this DLL. I think you should update the 
add_jvm_dll_directory_to_path() to use the new python 3.8 add_dll_directory() 
function instead of its current messing with the Path environment variable. If 
you think of making --find-jvm-dll the default on Windows/python3.8, then the 
add_jvm_dll_directory_to_path() function in windows.py should verify that 
jvm.dll isn't already findable, before adding a DLL path if necessary.
Same issue with the changes in jcc3/python.py: you should not depend on 
JAVA_HOME but share the same logic in jcc3/windows.py (assuming that logic is 
still correct, of course).
In other words, does --find-jvm-dll work for you ? (without your patch).

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (PYLUCENE-62) Not finding jvm.dll on windows

[Andi Vajda (Jira)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491471#comment-17491471
 ] 

Andi Vajda commented on PYLUCENE-62:


It looks like finding the jvm.dll is an old problem on Windows and python 3.8 
just made it a bit worse. If you look in jcc3/__init__.py, which you modified 
in this patch, you can see that something similar is done when the 
--find-jvm-dll command line flag is set.
The code in jcc3/windows.py has something a bit more involved than just relying 
on JAVA_HOME to locale this DLL. I think you should update the 
add_jvm_dll_directory_to_path() to use the new python 3.8 add_dll_directory() 
function instead of its current messing with the Path environment variable. If 
you think of making --find-jvm-dll the default on Windows/python3.8, then the 
add_jvm_dll_directory_to_path() function in windows.py should verify that 
jvm.dll isn't already findable, before adding a DLL path if necessary.
Same issue with the changes in jcc3/python.py: you should not depend on 
JAVA_HOME but share the same logic in jcc3/windows.py (assuming that logic is 
still correct, of course).
In other words, does --find-jvm-dll work for you ? (without your patch).

> Not finding jvm.dll on windows
> --
>
> Key: PYLUCENE-62
> URL: https://issues.apache.org/jira/browse/PYLUCENE-62
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Petrus Hyvönen
>Priority: Major
> Attachments: add_dll_win.patch
>
>
> On recent versions of Python, the dll's seems to require to be added via the 
> os.add_dll_directory() function.
>  
> Apparently something changed in Python 3.8 regarding this, "Python 3.8 
> changed the DLL resolution order 
> [https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew];
> Thanks to:
> [https://github.com/conda-forge/python-feedstock/issues/552]
>  
> Proposed fix in a patch below. It can likely be rewritten in some more neat 
> way. :)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: issue with modules while building PyLucene

[Andi Vajda]

On Tue, 4 Jan 2022, Andi Vajda wrote:



On Tue, 4 Jan 2022, Dawid Weiss wrote:


You have to exclude that module-info.class from processing somehow, Andi.
It isn't a proper class indeed. Can jcc accept an exclusion pattern 
somehow?


Oh yes, that's not a problem, just add it via --exclude, let me try that and 
report back.


Yes, that worked like a charm.
PyLucene now builds with Lucene 9x sources and passes its tests.

Thank you for the clue !

Andi..



Andi..



Dawid

On Tue, Jan 4, 2022 at 7:36 PM Andi Vajda  wrote:



  Hi,

I was able to build PyLucene with Lucene 9.0 and have it pass all its
tests.
Now, I moved to branch_9x (to get access to the new collectRuntimeJars
Gradle task) and I'm hitting an issue that seems to be related to the new
work around java modules:

   Exception in thread "main" java.lang.NoClassDefFoundError: module-info
is
   not a class because access_flag ACC_MODULE is set

I now nothing about java modules so maybe this is trivial or non-sensical
but all JCC is doing with the Lucene jars in order to build PyLucene is to
load them, walk their class trees and, using reflection, generate wrappers
for the publicly accessible methods and some extra ones as well, as listed
in the JCC command line (at line 215 in PyLucene's Makefile here:
   https://svn.apache.org/repos/asf/lucene/pylucene/trunk/Makefile

Is there an easy way to disable the module feature ? (does this question
even make sense ? is there a proper way to do what JCC is doing with
modules
enabled ?)

Thanks !

Andi..

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: issue with modules while building PyLucene

[Andi Vajda]

On Tue, 4 Jan 2022, Dawid Weiss wrote:


You have to exclude that module-info.class from processing somehow, Andi.
It isn't a proper class indeed. Can jcc accept an exclusion pattern somehow?


Oh yes, that's not a problem, just add it via --exclude, let me try that and 
report back.


Andi..



Dawid

On Tue, Jan 4, 2022 at 7:36 PM Andi Vajda  wrote:



  Hi,

I was able to build PyLucene with Lucene 9.0 and have it pass all its
tests.
Now, I moved to branch_9x (to get access to the new collectRuntimeJars
Gradle task) and I'm hitting an issue that seems to be related to the new
work around java modules:

   Exception in thread "main" java.lang.NoClassDefFoundError: module-info
is
   not a class because access_flag ACC_MODULE is set

I now nothing about java modules so maybe this is trivial or non-sensical
but all JCC is doing with the Lucene jars in order to build PyLucene is to
load them, walk their class trees and, using reflection, generate wrappers
for the publicly accessible methods and some extra ones as well, as listed
in the JCC command line (at line 215 in PyLucene's Makefile here:
   https://svn.apache.org/repos/asf/lucene/pylucene/trunk/Makefile

Is there an easy way to disable the module feature ? (does this question
even make sense ? is there a proper way to do what JCC is doing with
modules
enabled ?)

Thanks !

Andi..

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

issue with modules while building PyLucene

[Andi Vajda]

 Hi,

I was able to build PyLucene with Lucene 9.0 and have it pass all its tests.
Now, I moved to branch_9x (to get access to the new collectRuntimeJars 
Gradle task) and I'm hitting an issue that seems to be related to the new 
work around java modules:


  Exception in thread "main" java.lang.NoClassDefFoundError: module-info is
  not a class because access_flag ACC_MODULE is set

I now nothing about java modules so maybe this is trivial or non-sensical 
but all JCC is doing with the Lucene jars in order to build PyLucene is to 
load them, walk their class trees and, using reflection, generate wrappers 
for the publicly accessible methods and some extra ones as well, as listed 
in the JCC command line (at line 215 in PyLucene's Makefile here:

  https://svn.apache.org/repos/asf/lucene/pylucene/trunk/Makefile

Is there an easy way to disable the module feature ? (does this question 
even make sense ? is there a proper way to do what JCC is doing with modules 
enabled ?)


Thanks !

Andi..

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

On Mon, 3 Jan 2022, Dawid Weiss wrote:


I've applied it to branch_9x and main, Andi.


Thank you, Dawid, I was able to get PyLucene to build and all its tests to 
pass with this code added to Lucene 9.0 from Lucene 9.x.


Andi..



D.

On Mon, Jan 3, 2022 at 6:34 PM Andi Vajda  wrote:



On Mon, 3 Jan 2022, Dawid Weiss wrote:


Hi Andi,

Try this:
https://github.com/apache/lucene/pull/576

if you run 'gradlew collectRuntimeJars' it'll compile module jars but

also

collect any runtime binary dependencies under each project's build

folder.

For example:


ls lucene/analysis/icu/build/runtimeJars

icu4j-70.1.jar
lucene-analysis-icu-10.0.0-SNAPSHOT.jar

Let me know if this works for you and I'll merge with main.


Yes, this is perfect. This is exactly what I was looking for.
Thanks !

Andi..



Dawid

On Sun, Jan 2, 2022 at 11:29 PM Andi Vajda  wrote:



Thank you, Dawid.

On Sat, 1 Jan 2022, Dawid Weiss wrote:


Or is there an easy way for me to request from the Lucene Gradle build

that these external jar files be put somewhere more accessible

It's a trivial problem to solve but the question isn't stated right - I
think you should decide which specific subprojects from Lucene you need
binary dependencies of. Then we can do any of the following:


For Lucene 8.x, these are the external jars I've needed to build

PyLucene:

   ANTLR_JAR=$(LUCENE)/expressions/lib/antlr4-runtime-4.5.1-1.jar
   ASM_JAR=$(LUCENE)/expressions/lib/asm-8.0.1.jar
   ASM_COMMONS_JAR=$(LUCENE)/expressions/lib/asm-commons-8.0.1.jar
   HPPC_JAR=$(LUCENE)/facet/lib/hppc-0.8.1.jar

I suspect that for Lucene 9 some version numbers changed.


1) prepare either a special task for you to collect everything for

pylucene

or (perhaps better)


Currently, ./gradlew jar gets me everything I need except for the

external

jar files of topic. I don't think a special task is needed for any of

the

Lucene .jar files. For the external ones, maybe ?


2) a separate project that would include all of Lucene sources, build

them

and prepare the above binaries,


I don't think that one fits: I get the sources from git and build the
Lucene jar files using Gradle's jar task.


3) a separate project that would only depend on Lucene binaries and

fetch

whatever else is needed based on POMs.


I don't understand enough about POMs to know how to reply here. If this

is

what Ivy was doing for us until Lucene 8.x then, yes, something like

that

using Gradle that puts the external jars in a place I can access via a
filesystem path would be great.


I haven't looked at PyLucene's makefiles but if you let me know which

one

of the above works best for you, I'll prepare something on the gradle

side.

If you do something for one of the subprojects (say, the expressions

one),

I
can then extend this to others as needed. From my newbie understanding

of

the Lucene Gradle build, I'd think that an extra task that "persists"

the

external jars somewhere accessible via a simple filesystem path usable
from
a Makefile (by simple I mean, not fishing them out of ~/.gradle) would

be

easiest to consume by the PyLucene build.

Andi..



Dawid


On Sat, Jan 1, 2022 at 6:37 PM Andi Vajda  wrote:



Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:


As a Gradle project you can depend on Lucene artifacts and use Gradle

Apis

in your build files.


Until 8.x, PyLucene is built via a Makefile that:
   - calls Ant to build Lucene, building a bunch of jars individually
   - calls Ant to build Lucene extensions (Java classes extending some
Lucene
 classes with native methods that are then implemented in Python)
   - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
   - inserts the Lucene extension classes into Lucene's Gradle build

via a

 new subproject called 'extensions'
   - calls Gradle to build all Lucene jars and the extra

extensions.jar

in

 one command: ./gradlew jar
   - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer

available.

They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in

there

but
that seems very brittle as there are multiple versions present there.

If at all possible, I'd like to not create a Maven project (PyLucene

is

not
a Java project), mess with pom.xml files or create a new Gradle

project

for
PyLucene.

But maybe I should actually create a new Gradle project for PyLucene

that

replaces its Makefile ? Or is there an easy way for me to request from

the

Lucene Gradle build that these external jar files be put somewhere

more

accessible ? Uwe, you say that they are present in the Luke .tgz ?

What

is

the task that produces the Luke .tgz ? I might just be able to fish

the

.jar
files out of it then. I tried assembleBinaryTgz but that only makes

the

Lucene one and assembleRelease fa

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

On Mon, 3 Jan 2022, Dawid Weiss wrote:


Hi Andi,

Try this:
https://github.com/apache/lucene/pull/576

if you run 'gradlew collectRuntimeJars' it'll compile module jars but also
collect any runtime binary dependencies under each project's build folder.
For example:


ls lucene/analysis/icu/build/runtimeJars

icu4j-70.1.jar
lucene-analysis-icu-10.0.0-SNAPSHOT.jar

Let me know if this works for you and I'll merge with main.


Yes, this is perfect. This is exactly what I was looking for.
Thanks !

Andi..



Dawid

On Sun, Jan 2, 2022 at 11:29 PM Andi Vajda  wrote:



Thank you, Dawid.

On Sat, 1 Jan 2022, Dawid Weiss wrote:


Or is there an easy way for me to request from the Lucene Gradle build

that these external jar files be put somewhere more accessible

It's a trivial problem to solve but the question isn't stated right - I
think you should decide which specific subprojects from Lucene you need
binary dependencies of. Then we can do any of the following:


For Lucene 8.x, these are the external jars I've needed to build PyLucene:
   ANTLR_JAR=$(LUCENE)/expressions/lib/antlr4-runtime-4.5.1-1.jar
   ASM_JAR=$(LUCENE)/expressions/lib/asm-8.0.1.jar
   ASM_COMMONS_JAR=$(LUCENE)/expressions/lib/asm-commons-8.0.1.jar
   HPPC_JAR=$(LUCENE)/facet/lib/hppc-0.8.1.jar

I suspect that for Lucene 9 some version numbers changed.


1) prepare either a special task for you to collect everything for

pylucene

or (perhaps better)


Currently, ./gradlew jar gets me everything I need except for the external
jar files of topic. I don't think a special task is needed for any of the
Lucene .jar files. For the external ones, maybe ?


2) a separate project that would include all of Lucene sources, build

them

and prepare the above binaries,


I don't think that one fits: I get the sources from git and build the
Lucene jar files using Gradle's jar task.


3) a separate project that would only depend on Lucene binaries and fetch
whatever else is needed based on POMs.


I don't understand enough about POMs to know how to reply here. If this is
what Ivy was doing for us until Lucene 8.x then, yes, something like that
using Gradle that puts the external jars in a place I can access via a
filesystem path would be great.


I haven't looked at PyLucene's makefiles but if you let me know which one
of the above works best for you, I'll prepare something on the gradle

side.

If you do something for one of the subprojects (say, the expressions one),
I
can then extend this to others as needed. From my newbie understanding of
the Lucene Gradle build, I'd think that an extra task that "persists" the
external jars somewhere accessible via a simple filesystem path usable
from
a Makefile (by simple I mean, not fishing them out of ~/.gradle) would be
easiest to consume by the PyLucene build.

Andi..



Dawid


On Sat, Jan 1, 2022 at 6:37 PM Andi Vajda  wrote:



Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:


As a Gradle project you can depend on Lucene artifacts and use Gradle

Apis

in your build files.


Until 8.x, PyLucene is built via a Makefile that:
   - calls Ant to build Lucene, building a bunch of jars individually
   - calls Ant to build Lucene extensions (Java classes extending some
Lucene
 classes with native methods that are then implemented in Python)
   - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
   - inserts the Lucene extension classes into Lucene's Gradle build

via a

 new subproject called 'extensions'
   - calls Gradle to build all Lucene jars and the extra extensions.jar

in

 one command: ./gradlew jar
   - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer

available.

They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in there
but
that seems very brittle as there are multiple versions present there.

If at all possible, I'd like to not create a Maven project (PyLucene is
not
a Java project), mess with pom.xml files or create a new Gradle project
for
PyLucene.

But maybe I should actually create a new Gradle project for PyLucene

that

replaces its Makefile ? Or is there an easy way for me to request from

the

Lucene Gradle build that these external jar files be put somewhere more
accessible ? Uwe, you say that they are present in the Luke .tgz ? What

is

the task that produces the Luke .tgz ? I might just be able to fish the
.jar
files out of it then. I tried assembleBinaryTgz but that only makes the
Lucene one and assembleRelease fails for me on checkWorkingCopyClean

since

I
have a bunch of changes not ready to be checked in...

Thank you for your insights !

Andi..


If you have the state of your work (do you use Gradle to build

already?)

we may be able to help you. You may need to write a Gradle task that

calls

your compiler. See ECJ (calls Java) or Ch

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

Thank you, Dawid.

On Sat, 1 Jan 2022, Dawid Weiss wrote:


Or is there an easy way for me to request from the Lucene Gradle build

that these external jar files be put somewhere more accessible

It's a trivial problem to solve but the question isn't stated right - I
think you should decide which specific subprojects from Lucene you need
binary dependencies of. Then we can do any of the following:


For Lucene 8.x, these are the external jars I've needed to build PyLucene:
  ANTLR_JAR=$(LUCENE)/expressions/lib/antlr4-runtime-4.5.1-1.jar
  ASM_JAR=$(LUCENE)/expressions/lib/asm-8.0.1.jar
  ASM_COMMONS_JAR=$(LUCENE)/expressions/lib/asm-commons-8.0.1.jar
  HPPC_JAR=$(LUCENE)/facet/lib/hppc-0.8.1.jar

I suspect that for Lucene 9 some version numbers changed.


1) prepare either a special task for you to collect everything for pylucene
or (perhaps better)


Currently, ./gradlew jar gets me everything I need except for the external 
jar files of topic. I don't think a special task is needed for any of the 
Lucene .jar files. For the external ones, maybe ?



2) a separate project that would include all of Lucene sources, build them
and prepare the above binaries,


I don't think that one fits: I get the sources from git and build the 
Lucene jar files using Gradle's jar task.



3) a separate project that would only depend on Lucene binaries and fetch
whatever else is needed based on POMs.


I don't understand enough about POMs to know how to reply here. If this is 
what Ivy was doing for us until Lucene 8.x then, yes, something like that 
using Gradle that puts the external jars in a place I can access via a 
filesystem path would be great.



I haven't looked at PyLucene's makefiles but if you let me know which one
of the above works best for you, I'll prepare something on the gradle side.


If you do something for one of the subprojects (say, the expressions one), I 
can then extend this to others as needed. From my newbie understanding of 
the Lucene Gradle build, I'd think that an extra task that "persists" the 
external jars somewhere accessible via a simple filesystem path usable from 
a Makefile (by simple I mean, not fishing them out of ~/.gradle) would be 
easiest to consume by the PyLucene build.


Andi..



Dawid


On Sat, Jan 1, 2022 at 6:37 PM Andi Vajda  wrote:



Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:


As a Gradle project you can depend on Lucene artifacts and use Gradle

Apis

in your build files.


Until 8.x, PyLucene is built via a Makefile that:
   - calls Ant to build Lucene, building a bunch of jars individually
   - calls Ant to build Lucene extensions (Java classes extending some
Lucene
 classes with native methods that are then implemented in Python)
   - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
   - inserts the Lucene extension classes into Lucene's Gradle build via a
 new subproject called 'extensions'
   - calls Gradle to build all Lucene jars and the extra extensions.jar in
 one command: ./gradlew jar
   - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer available.
They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in there
but
that seems very brittle as there are multiple versions present there.

If at all possible, I'd like to not create a Maven project (PyLucene is
not
a Java project), mess with pom.xml files or create a new Gradle project
for
PyLucene.

But maybe I should actually create a new Gradle project for PyLucene that
replaces its Makefile ? Or is there an easy way for me to request from the
Lucene Gradle build that these external jar files be put somewhere more
accessible ? Uwe, you say that they are present in the Luke .tgz ? What is
the task that produces the Luke .tgz ? I might just be able to fish the
.jar
files out of it then. I tried assembleBinaryTgz but that only makes the
Lucene one and assembleRelease fails for me on checkWorkingCopyClean since
I
have a bunch of changes not ready to be checked in...

Thank you for your insights !

Andi..


If you have the state of your work (do you use Gradle to build already?)
we may be able to help you. You may need to write a Gradle task that

calls

your compiler. See ECJ (calls Java) or Changes2html (calls python) tasks
as examples.

BTW, the jar files are hidden in the Gradle cache folder somewhere in

your

home dir. Bit to access them you need Gradle Apis.

Uwe

Am 31. Dezember 2021 18:24:47 UTC schrieb Uwe Schindler 
Hi,

The Lucene 9.0 binary tgz no longer contains 3rd party dependencies,

unless they are needed to run Luke.


Generally we expect people to parse the pom.xml files and download

artifacts as part of a downstream build. If you are able to use Maven, I'd
recommend to create a small Maven Java Project listing the Lucene
dependencies and ask 

Re: where is the antlr4 runtime jar ?

[Andi Vajda]

Thank you, Uwe.

On Fri, 31 Dec 2021, Uwe Schindler wrote:

As a Gradle project you can depend on Lucene artifacts and use Gradle Apis 
in your build files.


Until 8.x, PyLucene is built via a Makefile that:
  - calls Ant to build Lucene, building a bunch of jars individually
  - calls Ant to build Lucene extensions (Java classes extending some Lucene
classes with native methods that are then implemented in Python)
  - calls JCC to generate and compile C++/Python PyLucene

Now, with the Lucene Gradle build, the Makefile:
  - inserts the Lucene extension classes into Lucene's Gradle build via a
new subproject called 'extensions'
  - calls Gradle to build all Lucene jars and the extra extensions.jar in
one command: ./gradlew jar
  - calls JCC to generate and compile C++/Python PyLucene

But the antlr, asm, asm-commons and hppc jar files are no longer available.
They were made available via Ivy before, in the old Lucene ant build.

As you suggested, fishing around ~/.gradle, I can find them all in there but 
that seems very brittle as there are multiple versions present there.


If at all possible, I'd like to not create a Maven project (PyLucene is not 
a Java project), mess with pom.xml files or create a new Gradle project for 
PyLucene.


But maybe I should actually create a new Gradle project for PyLucene that 
replaces its Makefile ? Or is there an easy way for me to request from the 
Lucene Gradle build that these external jar files be put somewhere more 
accessible ? Uwe, you say that they are present in the Luke .tgz ? What is 
the task that produces the Luke .tgz ? I might just be able to fish the .jar 
files out of it then. I tried assembleBinaryTgz but that only makes the 
Lucene one and assembleRelease fails for me on checkWorkingCopyClean since I 
have a bunch of changes not ready to be checked in...


Thank you for your insights !

Andi..

If you have the state of your work (do you use Gradle to build already?) 
we may be able to help you. You may need to write a Gradle task that calls 
your compiler. See ECJ (calls Java) or Changes2html (calls python) tasks 
as examples.


BTW, the jar files are hidden in the Gradle cache folder somewhere in your 
home dir. Bit to access them you need Gradle Apis.


Uwe

Am 31. Dezember 2021 18:24:47 UTC schrieb Uwe Schindler :

Hi,

The Lucene 9.0 binary tgz no longer contains 3rd party dependencies, unless 
they are needed to run Luke.

Generally we expect people to parse the pom.xml files and download artifacts as 
part of a downstream build. If you are able to use Maven, I'd recommend to 
create a small Maven Java Project listing the Lucene dependencies and ask it to 
make a complete distribution.

If you have the source distribution, I'd recommend to make pylucene also use 
Gradle to build and then you can consume dependencies.

Uwe

Am 31. Dezember 2021 18:12:55 UTC schrieb Andi Vajda :


 Hi,

I've begun adapting PyLucene to Lucene 9.0 and switching it to using gradle.

The expressions sub-project depends on antlr4 and asm and I'm able to build
all of Lucene 9.0 without explicitely downloading these jar files.

The PyLucene build needs these jar files then to produce wrappers for the
entrypoints into the expressions sub-project classes.

Where are these jar files stored ?
$ find lucene-java-9.0.0 -name '*.jar' | grep antlr
produces nothing.

Thanks !

Andi..

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

where is the antlr4 runtime jar ?

[Andi Vajda]

 Hi,

I've begun adapting PyLucene to Lucene 9.0 and switching it to using gradle.

The expressions sub-project depends on antlr4 and asm and I'm able to build
all of Lucene 9.0 without explicitely downloading these jar files.

The PyLucene build needs these jar files then to produce wrappers for the 
entrypoints into the expressions sub-project classes.


Where are these jar files stored ?
$ find lucene-java-9.0.0 -name '*.jar' | grep antlr
produces nothing.

Thanks !

Andi..

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org