You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2003/10/02 21:35:58 UTC
using TestRunPerl without mod_perl.c
hi all...
I just discovered that if you use TestRunPerl to configure a third-party
module, and the installer points -apxs to an apache without mod_perl, the
test suite blows up due to mod_perl specific configuration directives in
httpd.conf.
the end result is that, within the tests, have_module('foo.c') works for
every module _except_ mod_perl, since if mod_perl isn't installed the test
suit never gets started.
anyway, I think it's a good practice to <IfModule> non-core directives, and
it looks like that is being done most of the time (Alias seems to be the
exception). the attached patch does that for mod_perl stuff.
--Geoff
Re: using TestRunPerl without mod_perl.c
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> hi again :)
>
> well, after giving this issue some (probably way too much) thought over
> the weekend, I have decided that unless there is a -1 floating around,
> I'm going to go ahead with the change as I initially suggested it.
>
> the main reason for my going ahead is something I realized after our
> last exchange. for the majority of TestRunPerl users (probably every
> single one, in fact) the change will have no effect on the behavior of
> Apache-Test: mod_perl specific directives in extra.conf.in will still
> make the server fail to start and the tests fail to run. so, what the
> changes will do it maintain existing behavior while giving users more
> flexibility than they currently have.
>
> at any rate, as I said, I'll commit later this afternoon unless there is
> a (very) good reason not to. I'll be happy to revert it later if, after
> actually using it, people don't like it and complain. if I have time in
> the near future, I'll even try to clean it up a bit (like removing
> PerlRequire from TestRun and sticking all of them in a single IfModule).
Well, I thought we agreed that the current behavior is not user-friendly, as
the test suite fails to start, rather than indicating to user that something
is wrong, before starting it. So you suggest to preserve this buggy behavior,
as an excuse for doing other things.
If you go ahead and do this change we will need to provide a way for users to
require mod_perl's availability before the suite starts. As suggested before
this could be done via a simple option to new and/or wrapped into a new
subclass. However IMHO, that needs to be a default behavior and having
mod_perl optional should be a configurable option/subclass, because the
majority of packages will not want it optional. So go ahead and do the change,
but please give this point a good thought before committing to it (releasing a
new version).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: using TestRunPerl without mod_perl.c
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
hi again :)
well, after giving this issue some (probably way too much) thought over the
weekend, I have decided that unless there is a -1 floating around, I'm going
to go ahead with the change as I initially suggested it.
the main reason for my going ahead is something I realized after our last
exchange. for the majority of TestRunPerl users (probably every single one,
in fact) the change will have no effect on the behavior of Apache-Test:
mod_perl specific directives in extra.conf.in will still make the server
fail to start and the tests fail to run. so, what the changes will do it
maintain existing behavior while giving users more flexibility than they
currently have.
at any rate, as I said, I'll commit later this afternoon unless there is a
(very) good reason not to. I'll be happy to revert it later if, after
actually using it, people don't like it and complain. if I have time in the
near future, I'll even try to clean it up a bit (like removing PerlRequire
from TestRun and sticking all of them in a single IfModule).
--Geoff
Re: using TestRunPerl without mod_perl.c
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> TestRunPerl implies that mod_perl is available. If it is not,
>> TestRunPerl should abort *before* it creates the config file, telling
>> user to use a mod_perl enabled server.
>
>
> I don't think it needs to be that way, and I'm not even sure it's a good
> idea. here's why...
>
> I may have a distribution that has parts that can work in both
> environments. say I'm writing a test for CGI.pm - I maybe want to have
> tests that use no server (generate HTML foo), then test stuff like
> $q->param, which behaves differently under mod_perl and mod_cgi.
>
> TestRunPerl is useful for configuring the mod_perl part of the server,
> but I don't necessarily want the _entire test suite_ to blow up just
> because mod_perl isn't in the httpd the user provided - there are still
> at least two parts of the module I can test. granted, with something as
> simple as CGI.pm I may not need the mod_perl widgets, but for other,
> more elaborate, modules I may. and the functionality for configuring
> mod_perl widgets is right there in TestRunPerl - no need for me to do it
> myself, either manually or through a subclass.
>
> now, say you have a mod_perl-only module, like some of the ones we have
> both written. you have a choice: you either want the tests to fail if
> mod_perl isn't present (like you do) or you want the tests to skip (like
> I do).
>
> the patch I have proposed allows both to coexist. for me, I can do
>
> plan tests => 1, have_module('mod_perl.c');
>
> while you can do
>
> die unless have_module('mod_perl.c');
>
> plan tests => 1;
>
> the end result is that everybody can achieve the behavior they want,
> which is kinda what Perl is all about :)
That requires too much duplicated code in all tests if the whole test suite
requires mod_perl.
>> There is nothing wrong with your patch, but it hides the problem
>> instead of fixing it.
>
>
> we clearly have different views of the problem. I think that
> Apache-Test should provide the tools to configure a server and run the
> tests, leaving it up to the tests to decide what fails and what passes.
> by making TestRunPerl (or anything else, for that matter) abort if a
> specific httpd module isn't found, you are taking away flexibility that
> would benefit test authors.
>
> in other words, Apache-Test should provide tools to make creating a test
> enviroment easier, not make decisions about whether 'make test' passes
> or fails.
Agreed. But that doesn't necessarily have to happen in TestRunPerl,
Apache-Test != TestRunPerl, and TestRunPerl != Apache-Test
There are a few ways to solve this conflict.
1) Have more than just TestRunPerl. e.g., keep TestRunPerl as it is (mod_perl
stuff is not opted by IfModule modperl) and fix it to die during the config
phase if mod_perl is not available. And add a subclass of TestRun which will
allow mod_perl to be optional. Bother can re-use most of the code.
2) Clean TestRunPerl to protect all mp directives with 'IfModule modperl', add
a new() option which will force a require of mp, or the opposite, have the mp
required by default, but have an option that will make it optional. I believe
we want to go with the latter, since most Apache:: modules on CPAN will
require mp to be available.
The first option is better for the end user[1], since they just need to pick
the right class and they have their httpd.conf with little IfMdodule noise.
But it requires more coding on the developer's side.
The second option makes it easier on developers, but harder on users[1], since
now they have to figure out the extra options and they end up with a noisier
httpd.conf.
*1 user == a 3rd party module developer.
How does that sound to you?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: using TestRunPerl without mod_perl.c
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> TestRunPerl implies that mod_perl is available. If it is not,
> TestRunPerl should abort *before* it creates the config file, telling
> user to use a mod_perl enabled server.
I don't think it needs to be that way, and I'm not even sure it's a good
idea. here's why...
I may have a distribution that has parts that can work in both environments.
say I'm writing a test for CGI.pm - I maybe want to have tests that use no
server (generate HTML foo), then test stuff like $q->param, which behaves
differently under mod_perl and mod_cgi.
TestRunPerl is useful for configuring the mod_perl part of the server, but I
don't necessarily want the _entire test suite_ to blow up just because
mod_perl isn't in the httpd the user provided - there are still at least two
parts of the module I can test. granted, with something as simple as CGI.pm
I may not need the mod_perl widgets, but for other, more elaborate, modules
I may. and the functionality for configuring mod_perl widgets is right
there in TestRunPerl - no need for me to do it myself, either manually or
through a subclass.
now, say you have a mod_perl-only module, like some of the ones we have both
written. you have a choice: you either want the tests to fail if mod_perl
isn't present (like you do) or you want the tests to skip (like I do).
the patch I have proposed allows both to coexist. for me, I can do
plan tests => 1, have_module('mod_perl.c');
while you can do
die unless have_module('mod_perl.c');
plan tests => 1;
the end result is that everybody can achieve the behavior they want, which
is kinda what Perl is all about :)
>
> There is nothing wrong with your patch, but it hides the problem instead
> of fixing it.
we clearly have different views of the problem. I think that Apache-Test
should provide the tools to configure a server and run the tests, leaving it
up to the tests to decide what fails and what passes. by making TestRunPerl
(or anything else, for that matter) abort if a specific httpd module isn't
found, you are taking away flexibility that would benefit test authors.
in other words, Apache-Test should provide tools to make creating a test
enviroment easier, not make decisions about whether 'make test' passes or fails.
--Geoff
Re: using TestRunPerl without mod_perl.c
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
>> why would you use TestRunPerl to test against not-modperl enabled
>> Apache? If by accident I think it is better to discover that and die
>> before even starting to run tests.
>
>
> in a third-party (CPAN) module, you don't have much control.
>
> say I want to test my module against mod_perl. I need to use
> TestRunPerl if I want stuff like modperl_inc.pl to work. but the
> end-user passes me
>
> perl Makefile.PL -apxs /some/no-perl/apache/bin/apxs
>
> and the server blows up. at least if you have no -apxs, you get a nice
> warning.
>
> the issue here is a real one for me - I'm working on a distribution
> where only one file is mod_perl based, and I can't assume that even
> though I want the mod_perl stuff enabled, the user actually has it.
I understand that. Please re-read my previous reply. To repeat:
TestRunPerl implies that mod_perl is available. If it is not, TestRunPerl
should abort *before* it creates the config file, telling user to use a
mod_perl enabled server. For DSO it's trivial, for static build 'httpd -l'
should do the trick.
There is nothing wrong with your patch, but it hides the problem instead of
fixing it. So what if all mp directives will be enclosed in IfModule? Your
tests won't work in any case.
>> Not quite so, TestRunPerl already assumes that mod_perl is available.
>
>
> that's a bad assumption. since you configure TestRunPerl from the perl
> Makefile.PL stage, you can't know what the end-user has on his system.
Not really, you don't run TestRunPerl's configure from Makefile.PL, only from
t/TEST.
> besides, if you want to do
>
> t/TEST -apxs /with-modperl/bin/apxs
>
> t/TEST -apxs /without-modperl/bin/apxs
>
> I think that should be ok, and you have have_module('mod_perl.c') to
> allow just that.
>
>> Adding noise to httpd.conf doesn't make things better.
>
>
> it's not noise. if it were then there would be no reason to <IfModule>
> out the LoadModule statement for mod_perl.
It's there to prevent loading mod_perl DSO if someone messed up and re-built a
static mod_perl without fixing their global httpd.conf (which previously was
dynamic). It's not really needed I believe.
>> Besides if you could do:
>>
>> <IfModule mod_perl.c>
>> all mp configs
>> </IfModule>
>>
>> and not ifmodule for each directive that would be better I guess.
>
>
> yes, I thought so too. but the code for each of those is scattered
> about the suite, which makes it difficult to tie each of them together
> nicely.
That's true.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: using TestRunPerl without mod_perl.c
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> why would you use TestRunPerl to test against not-modperl enabled
> Apache? If by accident I think it is better to discover that and die
> before even starting to run tests.
in a third-party (CPAN) module, you don't have much control.
say I want to test my module against mod_perl. I need to use TestRunPerl if
I want stuff like modperl_inc.pl to work. but the end-user passes me
perl Makefile.PL -apxs /some/no-perl/apache/bin/apxs
and the server blows up. at least if you have no -apxs, you get a nice warning.
the issue here is a real one for me - I'm working on a distribution where
only one file is mod_perl based, and I can't assume that even though I want
the mod_perl stuff enabled, the user actually has it.
>
>> the end result is that, within the tests, have_module('foo.c') works
>> for every module _except_ mod_perl, since if mod_perl isn't installed
>> the test suit never gets started.
>
>
> Again, it should be solved at a much earlier stage, rather than waiting
> for the server to start. It should alert the user during the config
> stage and die right there.
>
>> anyway, I think it's a good practice to <IfModule> non-core
>> directives, and it looks like that is being done most of the time
>> (Alias seems to be the exception). the attached patch does that for
>> mod_perl stuff.
>
>
> Not quite so, TestRunPerl already assumes that mod_perl is available.
that's a bad assumption. since you configure TestRunPerl from the perl
Makefile.PL stage, you can't know what the end-user has on his system.
besides, if you want to do
t/TEST -apxs /with-modperl/bin/apxs
t/TEST -apxs /without-modperl/bin/apxs
I think that should be ok, and you have have_module('mod_perl.c') to allow
just that.
> Adding noise to httpd.conf doesn't make things better.
it's not noise. if it were then there would be no reason to <IfModule> out
the LoadModule statement for mod_perl.
> Besides if you
> could do:
>
> <IfModule mod_perl.c>
> all mp configs
> </IfModule>
>
> and not ifmodule for each directive that would be better I guess.
yes, I thought so too. but the code for each of those is scattered about
the suite, which makes it difficult to tie each of them together nicely.
--Geoff
Re: using TestRunPerl without mod_perl.c
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> hi all...
>
> I just discovered that if you use TestRunPerl to configure a third-party
> module, and the installer points -apxs to an apache without mod_perl,
> the test suite blows up due to mod_perl specific configuration
> directives in httpd.conf.
why would you use TestRunPerl to test against not-modperl enabled Apache? If
by accident I think it is better to discover that and die before even starting
to run tests.
> the end result is that, within the tests, have_module('foo.c') works for
> every module _except_ mod_perl, since if mod_perl isn't installed the
> test suit never gets started.
Again, it should be solved at a much earlier stage, rather than waiting for
the server to start. It should alert the user during the config stage and die
right there.
> anyway, I think it's a good practice to <IfModule> non-core directives,
> and it looks like that is being done most of the time (Alias seems to be
> the exception). the attached patch does that for mod_perl stuff.
Not quite so, TestRunPerl already assumes that mod_perl is available. Adding
noise to httpd.conf doesn't make things better. Besides if you could do:
<IfModule mod_perl.c>
all mp configs
</IfModule>
and not ifmodule for each directive that would be better I guess.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com