Re: More basics on the perl-framework stuff..
On Sun, 23 Dec 2001, Stas Bekman wrote: > That means two different ways to add configuration. yup. because we're doing different things. and for the record: there are already more than 2 ways to add configuration. tho only one to run the CONFIGURE routine. > Why cannot we make the .pm scanner more generic? because it was designed to be specific to modperl and it will stay that way. in fact, it might become even more specific to modperl in the future. > The magic is not mod_perl specific. most of configure_pm_tests is mod_perl specific. > The __DATA__ section can work for non-modperl, so does > APACHE_TEST_CONFIGURE. right, which is why i pointed out that we should just run add_module_config() and run_apache_test_config() on these other files, which are generic routines.
Re: More basics on the perl-framework stuff..
Doug MacEachern wrote: > On Fri, 21 Dec 2001, Stas Bekman wrote: > > >>I was thinking some more about this issue and came to a conclusion that >>there is nothing we should add, since we have already a working solution: >> > > close, but the current .pm scanner a bit too specific to mod_perl in terms > of location (where the .pm's have to live) and magic performed. how about > scanning for *.t.conf (or whatever extension), that just does the > $self->add_module_config and $self->run_apache_test_config parts? > > then we could have: > t/modules/access.t > t/modules/access.t.conf That means two different ways to add configuration. Why cannot we make the .pm scanner more generic? e.g. scan everything under t/. The magic is not mod_perl specific. The __DATA__ section can work for non-modperl, so does APACHE_TEST_CONFIGURE. So if you want the extra config just create the .pm file anywhere (or in a special location if we don't make the scanner=='scan all') the same way if you wanted to created the response part, but just leave the response part out. Think of it as naming access.pm instead of access.t.conf. Of course I realize that there can be other .pm files which shouldn't be scanned, and if they do get scanned, something should tell the scanner whether it's a candidate for having an extra configuration, or just a package (e.g. I create PerlRequire.pm packages for the testing and they aren't handlers) I think if we scan only the 't/response' directory that would be actually fine. In fact we can move the modperl response files under t/response (those that aren't there yet). _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: More basics on the perl-framework stuff..
On Fri, 21 Dec 2001, Stas Bekman wrote: > I was thinking some more about this issue and came to a conclusion that > there is nothing we should add, since we have already a working solution: close, but the current .pm scanner a bit too specific to mod_perl in terms of location (where the .pm's have to live) and magic performed. how about scanning for *.t.conf (or whatever extension), that just does the $self->add_module_config and $self->run_apache_test_config parts? then we could have: t/modules/access.t t/modules/access.t.conf
Re: More basics on the perl-framework stuff..
I was thinking that the best solution would be to encode the need for scanning a certain file in its name. e.g. foo.conf.t or foo.c.t, foo.ct (like this one the best since it won't appear in the tests stats output), so you still have one file and no need to open the files at all. The only caveat is if you decide to add the config part to an existing test you have to re-name it in cvs, plus MANIFEST file. Not sure which of the evils is less of an evil :) well first there is the same problem as above, if authors forget to name their files special. second, having to rename files is no good. third, there will either be funny looking test output or we have to rewrite Test::Harness to rip the special part of the name out. I was thinking some more about this issue and came to a conclusion that there is nothing we should add, since we have already a working solution: The response part of the test allows you to specify APACHE_TEST_CONFIGURE and __DATA__, so if you have only the request part of the test (.t) just add an empty response part (.pm) where you can add the __DATA__ section that can push stuff to .conf and APACHE_TEST_CONFIGURE for doing things during t/TEST -config. The only change we need is that if the file doesn't specify a handler its corresponding won't be automatically added to .conf. (or we have add some other indication of the the empty response part which serves only for configuration). Why do I think that this is a good thing? Because the configuration that you want to add to .conf is relevant to the response part not the request part. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: More basics on the perl-framework stuff..
On Thu, 13 Dec 2001, Stas Bekman wrote: > I guess 'restrictive' wasn't the right word. I've a gut feeling that > test writers will not remember that it must be a first line and there > will be no warnings that they've done it wrong (e.g. put it as a seconf > line). Oh well. i don't think we should worry about that. > I was thinking that the best solution would be to encode the need for > scanning a certain file in its name. e.g. foo.conf.t or foo.c.t, foo.ct > (like this one the best since it won't appear in the tests stats > output), so you still have one file and no need to open the files at > all. The only caveat is if you decide to add the config part to an > existing test you have to re-name it in cvs, plus MANIFEST file. Not > sure which of the evils is less of an evil :) well first there is the same problem as above, if authors forget to name their files special. second, having to rename files is no good. third, there will either be funny looking test output or we have to rewrite Test::Harness to rip the special part of the name out.
Re: More basics on the perl-framework stuff..
Stas Bekman wrote: > > My last suggestion was to have a single file with test and config > inside. The problem is scanning many files, which I suggested to solve > by having a special naming (e.g. .ct instead of .t) to mark certain > files that they include extra configuration. I would prefer to have the one-time-per-setup overhead of scanning all the .t files, rather than polluting the namespace with special-purpose extension. MHO. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
Re: More basics on the perl-framework stuff..
Rodent of Unusual Size wrote: I don't mind to having to include the stuff that foo.t needs in foo.conf.in, as long as the two are co-located. The part to which I object is having the config stuff either in a separate directory, or having to manually mung an existing file (e.g., extras.conf.in) for it. I want a drop-in ability: put the file(s) somewhere, run Makefile.PL and -clean again, and bingo. That being said, I even more like the idea of having a CONFIGURE method actually *in* foo.t. The fewer files are involved, the less likely things are to get out of synch. But if foo.t isn't a package/module, I'll have to leave it to you experts to figure out how to make it happen, since 'foo->CONFIGURE' isn't (directly) an option. Though elegant. My last suggestion was to have a single file with test and config inside. The problem is scanning many files, which I suggested to solve by having a special naming (e.g. .ct instead of .t) to mark certain files that they include extra configuration. I've explained the caveat of such an approach in my prev reply. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: More basics on the perl-framework stuff..
I don't mind to having to include the stuff that foo.t needs in foo.conf.in, as long as the two are co-located. The part to which I object is having the config stuff either in a separate directory, or having to manually mung an existing file (e.g., extras.conf.in) for it. I want a drop-in ability: put the file(s) somewhere, run Makefile.PL and -clean again, and bingo. That being said, I even more like the idea of having a CONFIGURE method actually *in* foo.t. The fewer files are involved, the less likely things are to get out of synch. But if foo.t isn't a package/module, I'll have to leave it to you experts to figure out how to make it happen, since 'foo->CONFIGURE' isn't (directly) an option. Though elegant. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
Re: More basics on the perl-framework stuff..
Doug MacEachern wrote:
On Thu, 13 Dec 2001, Stas Bekman wrote:
agreed, but the other suggestion to check the first line of .t is too
restrictive.
how so? the first line thing is just to say 'scan this file'. if the
magic isn't on the first line, the file isn't scanned.
I guess 'restrictive' wasn't the right word. I've a gut feeling that
test writers will not remember that it must be a first line and there
will be no warnings that they've done it wrong (e.g. put it as a seconf
line). Oh well.
Also when you want to get to the CONFIGURE section you have to require()
the file, which means it'll run the code in it, which is not good.
(compare with .pm, where everything is made of functions).
right. so we do it different from .pm's and just eval the 'sub CONFIGURE
{...}' part. and for good luck, as part of the eval we can toss in:
use Apache::Test;
use Apache::TestUtil;
etc.
if the CONFIGURE sub needs anything else, it can 'require' it. no more
painful to the user than having it another file.
ok.
I was thinking that the best solution would be to encode the need for
scanning a certain file in its name. e.g. foo.conf.t or foo.c.t, foo.ct
(like this one the best since it won't appear in the tests stats
output), so you still have one file and no need to open the files at
all. The only caveat is if you decide to add the config part to an
existing test you have to re-name it in cvs, plus MANIFEST file. Not
sure which of the evils is less of an evil :)
Also notice that Ken's request is different from what CONFIGURE does.
CONFIGURE doesn't add stuff to .conf, the __DATA__ section does.
i know that. i brought CONFIGURE into the conversation because if we're
going to scan .t's for __DATA__ we might as well look for CONFIGURE too
while we're there.
got it now.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: More basics on the perl-framework stuff..
On Thu, 13 Dec 2001, Stas Bekman wrote:
> agreed, but the other suggestion to check the first line of .t is too
> restrictive.
how so? the first line thing is just to say 'scan this file'. if the
magic isn't on the first line, the file isn't scanned.
> Also when you want to get to the CONFIGURE section you have to require()
> the file, which means it'll run the code in it, which is not good.
> (compare with .pm, where everything is made of functions).
right. so we do it different from .pm's and just eval the 'sub CONFIGURE
{...}' part. and for good luck, as part of the eval we can toss in:
use Apache::Test;
use Apache::TestUtil;
etc.
if the CONFIGURE sub needs anything else, it can 'require' it. no more
painful to the user than having it another file.
> Also notice that Ken's request is different from what CONFIGURE does.
> CONFIGURE doesn't add stuff to .conf, the __DATA__ section does.
i know that. i brought CONFIGURE into the conversation because if we're
going to scan .t's for __DATA__ we might as well look for CONFIGURE too
while we're there.
Re: More basics on the perl-framework stuff..
Doug MacEachern wrote: On Wed, 12 Dec 2001, Stas Bekman wrote: another idea would be to have a second file for this purpose. So if you have foo.t you'd add foo(.t?).conf.in in the same directory with whatever things you want. This is a snap to add (we already scan t/conf for .in files now we can just scan all dirs under t/ recursively. sure, that would be easy. but would we then have yet another file to implement the CONFIGURE routine? in any case, it would be nice if a .t could be totally self-contained with all three. agreed, but the other suggestion to check the first line of .t is too restrictive. Also when you want to get to the CONFIGURE section you have to require() the file, which means it'll run the code in it, which is not good. (compare with .pm, where everything is made of functions). Also notice that Ken's request is different from what CONFIGURE does. CONFIGURE doesn't add stuff to .conf, the __DATA__ section does. CONFIGURE prepares the environment, creating extra files, etc. So if you want a similarity with .pm, it should go to the __DATA__ section of the .t file too. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: More basics on the perl-framework stuff..
On Wed, 12 Dec 2001, Stas Bekman wrote: > another idea would be to have a second file for this purpose. So if you > have foo.t you'd add foo(.t?).conf.in in the same directory with > whatever things you want. This is a snap to add (we already scan t/conf > for .in files now we can just scan all dirs under t/ recursively. sure, that would be easy. but would we then have yet another file to implement the CONFIGURE routine? in any case, it would be nice if a .t could be totally self-contained with all three.
Re: More basics on the perl-framework stuff..
Doug MacEachern wrote: On Mon, 10 Dec 2001, Rodent of Unusual Size wrote: I have some lines that need to be added to extras.conf, but I'd prefer to embed them in the .t file rather than editing extras.conf.in. I want to be able to drop in a .t file without having to modify any of the existing framework to accommodate it. you can create a t/conf/foo.conf.in that will Include-d for you in httpd.conf. i realize it would be nicer to have the conf in the .t, but we've tried to avoid that in the interest of startup time. there's already close to 100 .t files we'd need to scan. we have a similar problem wanting to implement a CONFIGURE routine for .t's to create directories, files, etc. at configuration-generation time rather than test-run time. how about if opened each .t and looked at the first line for a flag that says scan me: % cat foo.t #APACHE_HTTPD_TEST: configure use Apache::Test; ... if we require the first line have this token (or something like it), we can avoid the wasted time of scanning all the .t's that do not have any configuration info. another idea would be to have a second file for this purpose. So if you have foo.t you'd add foo(.t?).conf.in in the same directory with whatever things you want. This is a snap to add (we already scan t/conf for .in files now we can just scan all dirs under t/ recursively. I think this preserves the locality as close as possible. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: More basics on the perl-framework stuff..
On Mon, 10 Dec 2001, Rodent of Unusual Size wrote: > I have some lines that need to be added to extras.conf, but I'd > prefer to embed them in the .t file rather than editing extras.conf.in. > I want to be able to drop in a .t file without having to modify > any of the existing framework to accommodate it. you can create a t/conf/foo.conf.in that will Include-d for you in httpd.conf. i realize it would be nicer to have the conf in the .t, but we've tried to avoid that in the interest of startup time. there's already close to 100 .t files we'd need to scan. we have a similar problem wanting to implement a CONFIGURE routine for .t's to create directories, files, etc. at configuration-generation time rather than test-run time. how about if opened each .t and looked at the first line for a flag that says scan me: % cat foo.t #APACHE_HTTPD_TEST: configure use Apache::Test; ... if we require the first line have this token (or something like it), we can avoid the wasted time of scanning all the .t's that do not have any configuration info.
More basics on the perl-framework stuff..
I have some lines that need to be added to extras.conf, but I'd prefer to embed them in the .t file rather than editing extras.conf.in. I want to be able to drop in a .t file without having to modify any of the existing framework to accommodate it. Can be done? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
