On Friday 17 March 2017, Andi Vajda wrote: > On Thu, 16 Mar 2017, Ruediger Meier wrote: > > On Thursday 16 March 2017, Andi Vajda wrote: > >> Indeed, this is a bug of mine. > >> What would you prefer: > >> - include the actual .jar files in the distribution archive > >> (tell tar to follow the symlinks when I build the PyLucene > >> distribution) - or exclude the symlinks (tell tar to exclude > >> symlinks); your running build would then use ivy to fetch them > > > > Usually my opinion is that tarballs should have the least possible > > dependencies. But in this case where all the deps are hosted on the > > same source (apache.org) I would not include it but download on > > build time (if user has not downloaded it manually already). > > +1, I'm leaning towards not including these .jar files as well. > It saves about 20Mb on the pylucene distribution tar file and they > can be obtained from ivy anyway. > > > Maybe we could even enhance the Makefile to automatically find an > > already installed lucene or download the latest minor version. IMO > > it makes no sense that pylucene users by default always use a > > non-bugfixed outdated lucene. And I saw on this mailing list how > > difficult it can be to get enough votes for a pylucene minor > > update. > > There is no such thing as a bugfixed Lucene. Each Lucene release has > new bug fixes but also new bugs, such is software development. Lucene > also breaks things on a regular basis inspite of being quite careful > about backwards compatibility, thus PyLucene unit tests have to be > checked for each release. > > The problem you're referring to would not be much of an issue if it > was easier to garner votes for a PyLucene release. A new release > would happen in lock step with each Lucene release, as was the case > in the past, a few years ago. There is a Lucene 6.5 release being > talked about and I intend to release a PyLucene 6.5 shortly > thereafter.
Well, I was speaking about the minor maintenance updates like 6.4.2 but you know surely better about the quality of lucene updates. > > The same goes for the jcc python package which the user has to > > install manually anyways. We don't need to ship it with pylucene. I > > guess jcc would be far more famous if it would be hosted decoupled > > of pylucene. IMO jcc is a really amazing good working thing. > > pylucene is just a nice example how easy you can use java libs via > > python. > > Thank you for the kind words. JCC is already available without > PyLucene from Python's PyPI: https://pypi.python.org/pypi/JCC/2.23 > JCC gets released on PyPI at the same time as the main Apache > PyLucene release. > > I agree that PyLucene is just an example of JCC usage but it's the > main one and PyLucene has been driving the features of JCC. Yep, jcc only exists because of pylucene. And good that pylucene's development and user base guarantees that jcc will be well maintained in future too. On the other hand pylucene may be some kind of show stopper for jcc. Why wasn't the old experimental jcc/py3 port released quickly on PyPI 7 years ago? Is there any chance to get the recent jcc/py3 port released soon even pylucene still cares for stable py2 only? I mean releasing jcc for py3 cannot break any existing project. No need to wait for the right time to test it more carefully. Cheers, Rudi
