You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pylucene-dev@lucene.apache.org by Bill Janssen <ja...@parc.com> on 2009/04/23 19:44:32 UTC

installing pylucene-2.4.1

I've just tried installing 2.4.1, and I've got a few suggestions for
packaging.

1. Put a plain-text version of readme.html in README, automatically
   generated from readme.html (or whatever), as part of the src-dist
   build process.  I always hate it when I visit a README, and it says,
   "You fool!  You should be looking at doc/documentation/readme.html!"

2. Ditto for the INSTALL file.

3. Oh, and by the way, looking at readme.html is tough.  The string
   "doc/documentation/readme.html" will almost always be read as just
   "documentation/readme.html".  I'd suggest calling that directory
   "doc/dist", or some such, instead of "doc/documentation".

4.  If there's a top-level "build.xml" file, lots of users (me, too :-)
    will think that they can just type "ant" to build the package.  That
    should either "just work", or you should rename the build.xml file
    to something less obvious, like "to-be-invoked-by-the-Makefile.xml".

5.  Get rid of editing the Makefile, if you can.  Would you like me to
    write an autoconf script for this?

Bill

Re: installing pylucene-2.4.1

Posted by Andi Vajda <va...@apache.org>.
On Thu, 23 Apr 2009, Bill Janssen wrote:

>> Renaming build.xml to something more obscure could be done.
>> Would you like to send in a patch ?
>
> Didn't I just do that :-?  No, I'll let you deal with it.

Done.

Andi..

Re: installing pylucene-2.4.1

Posted by Andi Vajda <va...@apache.org>.
On Apr 23, 2009, at 13:15, Bill Janssen <ja...@parc.com> wrote:

> Andi Vajda <va...@apache.org> wrote:
>
>> If Apache Forrest, which is used to produce the web site, can be  
>> used to
>> generate plain text, then this should be used for sure. What I  
>> don't want
>> to do is maintain two versions of the docs, even one pagers.
>
> No, of course not.  That's why I use ReST for the UpLib docs.  I know
> nothing about Apache Forrest.

Apache Forrest is what is used on the Apache Lucene site. I had to  
learn enough about it to get what we have today on the PyLucene site.  
I know that it makes a PDF page for every web page. Maybe it can make  
a plain text page too ?

>>> 4.  If there's a top-level "build.xml" file, lots of users (me,  
>>> too :-)
>>>   will think that they can just type "ant" to build the package.   
>>> That
>>>   should either "just work", or you should rename the build.xml file
>>>   to something less obvious, like "to-be-invoked-by-the- 
>>> Makefile.xml".
>>
>> Renaming build.xml to something more obscure could be done.
>> Would you like to send in a patch ?
>
> Didn't I just do that :-?  No, I'll let you deal with it.
>
>> Sadly, the alternative here is autoconf. If you'd like to write an  
>> autoconf
>> script that works for all the variants of Python/Java/OS currently  
>> supported
>> in the Makefile, that would be excellent.
>
> Yes, I've already got most of that for UpLib.
>
>> Unless you're on Mac, editing JCC's setup.py is also required. If  
>> you write
>> an autoconf script for PyLucene, be sure to also include the  
>> generation of
>> JCC's setup.py, otherwise you've only addressed half of the problem.
>
> Right.
>
>> I expect that cracking the nut of finding the JDK on each and every  
>> Linux
>> distro is going to present a challenge. Providing command line  
>> arguments to
>> override what configure finds is probably a must.
>
> Exactly.  Linux/Java is a mess -- whoops, I meant to say, a seething
> ferment of opportunity!  I've got a script called "figure-linux- 
> java.py".

Nice !

Andi..

>
>
> Bill

Re: installing pylucene-2.4.1

Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:

> If Apache Forrest, which is used to produce the web site, can be used to 
> generate plain text, then this should be used for sure. What I don't want 
> to do is maintain two versions of the docs, even one pagers.

No, of course not.  That's why I use ReST for the UpLib docs.  I know
nothing about Apache Forrest.

> > 4.  If there's a top-level "build.xml" file, lots of users (me, too :-)
> >    will think that they can just type "ant" to build the package.  That
> >    should either "just work", or you should rename the build.xml file
> >    to something less obvious, like "to-be-invoked-by-the-Makefile.xml".
> 
> Renaming build.xml to something more obscure could be done.
> Would you like to send in a patch ?

Didn't I just do that :-?  No, I'll let you deal with it.

> Sadly, the alternative here is autoconf. If you'd like to write an autoconf 
> script that works for all the variants of Python/Java/OS currently supported 
> in the Makefile, that would be excellent.

Yes, I've already got most of that for UpLib.

> Unless you're on Mac, editing JCC's setup.py is also required. If you write 
> an autoconf script for PyLucene, be sure to also include the generation of 
> JCC's setup.py, otherwise you've only addressed half of the problem.

Right.

> I expect that cracking the nut of finding the JDK on each and every Linux 
> distro is going to present a challenge. Providing command line arguments to 
> override what configure finds is probably a must.

Exactly.  Linux/Java is a mess -- whoops, I meant to say, a seething
ferment of opportunity!  I've got a script called "figure-linux-java.py".

Bill

Re: installing pylucene-2.4.1

Posted by Andi Vajda <va...@apache.org>.
On Thu, 23 Apr 2009, Bill Janssen wrote:

> I've just tried installing 2.4.1, and I've got a few suggestions for
> packaging.
>
> 1. Put a plain-text version of readme.html in README, automatically
>   generated from readme.html (or whatever), as part of the src-dist
>   build process.  I always hate it when I visit a README, and it says,
>   "You fool!  You should be looking at doc/documentation/readme.html!"

He, he. I didn't put "you fool" in there. Maybe I should add that :) ?

If Apache Forrest, which is used to produce the web site, can be used to 
generate plain text, then this should be used for sure. What I don't want 
to do is maintain two versions of the docs, even one pagers.

> 2. Ditto for the INSTALL file.
>
> 3. Oh, and by the way, looking at readme.html is tough.  The string
>   "doc/documentation/readme.html" will almost always be read as just
>   "documentation/readme.html".  I'd suggest calling that directory
>   "doc/dist", or some such, instead of "doc/documentation".
>
> 4.  If there's a top-level "build.xml" file, lots of users (me, too :-)
>    will think that they can just type "ant" to build the package.  That
>    should either "just work", or you should rename the build.xml file
>    to something less obvious, like "to-be-invoked-by-the-Makefile.xml".

Renaming build.xml to something more obscure could be done.
Would you like to send in a patch ?

> 5.  Get rid of editing the Makefile, if you can.  Would you like me to
>    write an autoconf script for this?

Sadly, the alternative here is autoconf. If you'd like to write an autoconf 
script that works for all the variants of Python/Java/OS currently supported 
in the Makefile, that would be excellent.

Unless you're on Mac, editing JCC's setup.py is also required. If you write 
an autoconf script for PyLucene, be sure to also include the generation of 
JCC's setup.py, otherwise you've only addressed half of the problem.

I expect that cracking the nut of finding the JDK on each and every Linux 
distro is going to present a challenge. Providing command line arguments to 
override what configure finds is probably a must.

Thanks !

Andi..