On Aug 26, 2009, at 11:44 AM, Michael Peters wrote:

> craig@anim... wrote:
>> The installation process needs to know at least:
>> 1. where the accompanying DB-building script should go
>
> Module::Build knows where to put bin/ or script/ files and it does  
> so according to how Perl and CPAN are configured. I assume EU::MM  
> does too.
>
So if I put the script in a subdirectory bin of Apache2-
CloseKeepAlive-n.nn/,
the install step should automatically put it somewhere in the path.
This is good information, thank you!

I have no idea what EU::MM is.  Candy from Europe?

>> 2. where the DB that the app builds should go
>
> That's probably something your application should allow to be  
> specified, either a command line option to the script or an option  
> to the module, or both.
>
My plan was to run the script the first time under Build.PL, to
verify that it succeeds and because without the DB there can be no
testing.  In which case, asking the user where to put the DB, and
propagating the answer to the script source and the module source,
seems to me like the easiest course for everyone.  This kind of
prompt is not evil, in that the automated testers can be handled
by giving the query a default, maybe '/tmp'.

>> How can such necessary things be determined, other than by asking
>> the user?
>
> If it's a run time option (and can be changed or multiple programs  
> can use this and thus want different values) don't ask for it at  
> install time.
>
It's not a run time option.  The subject is a mod_perl2 script, that
can only be used within the Apache2 server.  I can't conceive why the
DB name would ever change, and multiple programs won't use the module.

>> I was just going to add a note before or after these two queries,
>> that if they have a mod_perl2 library and want the module to go
>> there, they should "do this".
>
> Putting extra docs in your module is ok, but I personally wouldn't  
> repeat the docs that are already out there.
>
I personally regard "docs already out there" as things that should
be restated "in here" whenever the user can profit from them.

>> As I just wrote to Perrin off-list, since only a tiny fraction of
>> CPAN downloads are mod_perl2 modules, no one can configure CPAN
>> for a mod_perl2 library.
>
> All perl libraries should go in the same place IMO. Whether it's  
> Apache specific, or GTK or something else. I don't want to have to  
> mess with @INC just because someone put something someplace non-
> standard.

It seems that you and Perrin are in the same boat, which has "One Perl
Library For All" painted on it.  I am in a different boat with the
authors of various mod_perl books.  I set up my site under the guidance
of "Practical mod_perl" p. 34:

   "Now you have to select a directory where all the mod_perl scripts  
and
   modules will be placed. We usually create a directory called modperl
   under our home directory for this purpose (e.g., /home/stas/modperl),
   but it is also common to create a directory called perl under your
   Apache server root, such as /usr/local/apache/perl."

(It's /usr/local/apache2/plib on my site.)

This theme is echoed on p. 58 of the "mod_perl2 User's Guide":

   "You often need to adjust the contents of @INC before the server  
starts,
   usually to give the server additional places to look for your  
mod_perl code.
   There are several ways to do this:

   • startup.pl

   In the startup file you can use the lib pragma like so:

   use lib qw(/home/httpd/projectl/lib/tmp/lib);
   use lib qw(/home/httpd/project2/lib);

   • httpd.conf

   In httpd.conf you can use the PerlSwitches directive to pass  
arguments
   to Perl as you do from the command line.

   PerlSwitches -I/home/httpd/projectl/lib -I/tmp/lib
   PerlSwitches -I/home/httpd/project2/lib"

And on p. 61 of the "mod_perl Developer's Cookbook":

   "For a similar option, configure your startup.pl as
   use lib qw(/home/www/lib);
   ...
   By default, mod_perl adds two directories to @INC: ServerRoot/ and
   ServerRoot/lib/perl/, where ServerRoot is the value of the ServerRoot
   directive.
   ...
   If you are using a startup.pl to preload your modules, you will
   probably need to take advantage of the use lib syntax."

Given all this, I blithely talk about "the mod_perl library" as if
it's a standard part of every mod_perl site, and you and Perrin
regard me as someone from another planet.

Which is actually true, but that's another story.
>
>> So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it
>> prompts the user to enter the path to 'mm', which is then passed
>> to Devel::CheckLib.  The query is accompanied by a note showing
>> the URL from which 'mm' can be downloaded.
>
> Personally, I'd just bomb out if you can't find the lib (and  
> Devel::CheckLib is good for that). Give the user a message that you  
> can't find the library and then exit. I doubt that someone who has  
> a library that's not in the system libs will know where it is, and  
> if they do they can just as easily set LD_LIBRARY_PATH themselves.
>
This happens to me fairly regularly when installing things, that the
install script asks me a question I can't answer.  Which I handle
by starting up another shell that I use to find the answer, then go
back to the first shell and enter it.

>> On the other hand, my latest version 0.58 has only been tested by
>> one tester, a week after uploading it.  Maybe that's because of
>> the new query in Makefile.PL!
>
> That's why prompts are evil. Automated tests won't work. So just  
> bomb out and at least you'll get lots of UNKNOWN test results which  
> is better than nothing :)

Your attitudes and mine are so different!  First, I would never just
"give the user a message that you can't find the library and then exit".
It would have to include the URL where they can get the library.

Second, I regard each UNKNOWN result as a personal failing, in that
I didn't give the tester the information he/she needed to produce a
more useful result.  So UNKNOWN is worse than nothing.

More than enough said, at least for now,
cmac