On Aug 26, 2009, at 11:44 AM, Michael Peters wrote:
cr...@animalhead.com 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
