Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage---
-- justin ]
On Monday, May 19, 2003, at 06:41 PM, Stas Bekman wrote:
So we need to figure out how to enforce UNINST the old Apache/test.pm
if any.
For example we could adjust MY::install to unlink it, without messing
with UNINST=1, though the latter will be the simplest.
Sounds okay to me. I don't know much about the MY:: stuff in
Makefile.PL.
and I haven't tried any tests that use Apache::test using the new one.
I think Geoff's Apache::Clean for mp1 uses it. So does older libapreq.
I just tested it with MasonX::ApacheHandler::WithCallbacks, and it
looks like it works pretty well. It failed different tests than it did
with the old Apache::test that I have in the distribution (which I
didn't know was failing any!), but that's likely to be some error on my
part or due to a change in Apache::test rather than a flaw in the
approach you're taking to the case-insensitive problem. So I would say
that it works pretty well.
in our case it's then much simpler. Since we don't have
lib/Apache/test.pm, we can simply test:
my $is_case_insensitive = -e catfile qw(lib Apache test.pm);
Ah, yes, of course. So there _is_ a simple way to test for it!
Other than the convenience, Apache::Test is used in at least two books
('mod_perl cookbook', and most likely 'practical mod_perl' too. So
it's a bummer to have these in Errata if we can find an acceptible
workaround.
It's a trade-off. Either well-documented errata for those two books, or
potential support issues going forward. But you already know that. Your
call.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- -- justin ] On Monday, May 19, 2003, at 05:08 PM, Stas Bekman wrote: That's right. Let's try this next: I've attached a new patch, which moves the creation of lib/Apache/test.pm into a Makefile.PL. On case-insensitive systems it'll overwrite lib/Apache/Test.pm. That appears to work, but it didn't uninstall the old test.pm, and I haven't tried any tests that use Apache::test using the new one. I wish there was a simple test to figure out whether a filesystem is case-insensitive. I think that Perl itself does something like this: use File::Spec::Functions qw(catfile); my $file = catfile 't', 'TestTest'; open F, $file or die Cannot open $file: $!; close F; my $is_case_insensitive = -e catfile 't', 'testtest'; unlink $file; Also could it possible that under the same OS one partition is case-insensitive while the other is not? If so, what happens if the package is built on one but the target is the other? Oh, fer cryin' out loud, I don't know. Rename it Apache::Tester and don't worry about it, I say. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- [ This message is resent on behalf of David Wheeler [EMAIL PROTECTED]. -- justin ] On Monday, May 19, 2003, at 03:43 PM, Stas Bekman wrote: That's the trick. Each of these files contains both Apache::test and Apache::Test (do you see that each has require() called twice?). So it doesn't matter which one gets overwritten. Give it a try. But you can't have them both in the tarball, because users will get an error when they unpack them and will send you bug reports. Here's what happens when I apply the patch, just to give you an idea. mercury% patch -p0 ~/Desktop/patch The next patch would create the file Apache-Test/lib/Apache/test.pm, which already exists! Assume -R? [n] Apply anyway? [n] y patching file Apache-Test/lib/Apache/test.pm Patch attempted to create file Apache-Test/lib/Apache/test.pm, which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file Apache-Test/lib/Apache/test.pm.rej patching file Apache-Test/lib/Apache/test_mp1.pm patching file Apache-Test/lib/Apache/TestReal.pm patching file Apache-Test/lib/Apache/Test.pm David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- [ This message is resent on behalf of David Wheeler [EMAIL PROTECTED]. -- justin ] On Tuesday, May 13, 2003, at 08:08 PM, Stas Bekman wrote: If an old mod_perl 1.0 is installed and it overrides Apache::Test, Makefile.PL will simply fail to satisfy the requirement of a specific version (because Apache::test's version is smaller than Apache::Test's). Not sure I follow you here. CPAN.pm checks for such dependencies, but Makefile.PL, AFAIK, does not. And CPANPLUS doesn't work right, FWIW, because Apache::test has no version number at all, which CPANPLUS (mistakenly) assumes means that it's up to date. However taking again this track of overriding test.pm, we may still have a problem in the following situation: root installs mod_perl 1.27 system-wide, user installs Apache::Test locally (can't unlink Apache/test.pm), this can be a problem if user's @INC are added after the system-wide ones. But that would be silly, isn't it? Most likely, yes. If we are sticking with this track, we need to figure out the way to make sure that Apache/test.pm is nuked. David, if Apache-Test includes Apache/test.pm and Apache/Test.pm is it ensured that any other occurance of Apache/test.pm will be nuked? I think only if UNINST=1. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- -- justin ] On Thursday, May 8, 2003, at 05:44 PM, Stas Bekman wrote: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. Looks like if we can provide a clean implementation of (1) that's would be the best solution. Randy says that it shouldn't be a problem with winFU. If David says that it's cool with MacOSX, let's try to take this route then. It's much more likely that someone would install 1.27 over an Apache::Test installation on Mac OS X than it is on Win32, apparently. But if you were to release 1.28 with the new integrated Apache::Test, it probably wouldn't be too much of a problem. You might want to post a quick query to macosx@perl.org to get a general feel from the Mac OS X Perl community. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage---
[ This message is resent on behalf of Philippe M. Chiasson
[EMAIL PROTECTED]. -- justin ]
On Tue, 2003-05-13 at 07:36, Stas Bekman wrote:
Geoffrey Young wrote:
I actually like Apache::TestPlan, it's most of the functionality that
this module provides. but there are a few subs that are not. May be
this other functionality should move elsewhere.
given that almost all of the functions from the various Test* packages
are exported by default and almost nobody specifies an import list
currently with Apache::Test, I wouldn't worry too much about shuffling
stuff around later after the immediate problem has been fixed.
This is what I see now as the simplest solution at all fronts:
1) keep the distro name Apache-Test.
2) s|Apache/Test.pm|Apache/TestPlan.pm|
3) contents of Apache/TestPlan.pm:
package Apache::Test;
$Apache::Test::VERSION =3D '1.02';
package Apache::TestPlan;
# what was previously Apache::Test code follows
I decided to nevertheless plug these two lines in:
package Apache::Test;
$Apache::Test::VERSION =3D '1.02';
so that CPAN will still index Apache::Test, and we can still tell CPAN.pm to
install Apache::Test, same for dependencies list. Also that's where we
maintain the distro's version.
Usage-wise, the only change you have to do is this:
perl -pi -e 's|use Apache::Test([\s;])|use Apache::TestPlan$1|' files
Is everybody happy with that solution?
[late on this thread, but nontheless] I also like it
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- =
-
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634=
E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3=
A5A5
Q: It is impossible to make anything foolproof because fools are so ingenio=
us.
perl -e'$$=3D\${gozer};{$_=3Dunpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$+=
+redo}'
--=-16Hpeuu7KHwOm+VqGGS3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQA+wLCfyzKhB4jDpaURAusVAJ9PcjA/K65PlieSZfIN26xNIq/e9ACcC+fQ
p0oiGEqYX8/JEYzUo1gs5b4=
=OPin
-END PGP SIGNATURE-
--=-16Hpeuu7KHwOm+VqGGS3--
---End Message---
can I help with docs?
---BeginMessage--- [ This message is resent on behalf of Jeremy Brown [EMAIL PROTECTED]. -- justin ] Hi, I found it pretty hard to configure flood with current documentation. I found some good examples with the package but nothing really covering conglomerates and other types of advanced setups. Can I help to write some documentation regarding it? I have figured out a few details and I can reference the code for more details. But is there anything that has been started with this information? There seems to be quite a bit of functionality that is missing from the current docs. thanks jeremy ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- -- justin ] On Tuesday, May 6, 2003, at 10:40 AM, Randy Kobes wrote: I'm beginning to think that, for all the up-front hassle of it, just renaming it to Apache::Tester or Test::Apache will avoid more headaches in the long run. That's a good point, although as Stas pointed out, it may cause some confusion with those already using Apache::Test. No more so than the Apache::TestLoad solution, and probably less. If one views (philosophically) Apache::Test as a major upgrade to Apache::test (with a different API), might it be reasonable to consider replacing those packages that use Apache::test with Apache::Test? For example, in the next mod_perl 1 release, require Apache-Test for the tests, and do away with Apache::test? This would require rewriting the tests, which might be worth it anyway, as a major illustration that Apache-Test works equally well with mod_perl 1 (I'd volunteer to look at that, as I'm on one of the offending systems). Even if you did port all the tests in mp1 to Apache::Test, we'd still have the problem of someone installing Apache::Test from CPAN, and then installing mod_perl 1.27 or earlier and thus restoring Apache::test. Lots of organizations are conservative, and wary of upgrading to a new release. I guess one advantage to this, recalling Stas' suggestion of putting the functionality of Apache::test into Apache::Test, is that two quite distinct test frameworks don't have to, officially, be supported. And it also, eventually, addresses the problem of installing mod_perl 1 after an Apache-Test installation and overwriting Apache/Test.pm with Apache/test.pm. Exactly. The downside, of course, is that mod_perl 1 is very stable, and so major changes like this aren't desireable. Another disadvantage is that there's 3rd party mod_perl 1 modules that use Apache::test (for example, Apache-Filter), and these would be affected. Right, although I think many of them include Apache::test in t/lib (I know mine does). Perhaps a compromise to the above is to just do this on Win32/Mac OSX (or even not changing the test framework at all in mod_perl 1, and just not install Apache/test.pm), and then just print out a warning that this is being done, and why. This wouldn't affect as many users, and in the Win32 world, and perhaps also on the Mac, I think users are used to major upgrades that aren't necessarily backwards compatible. It just seems cleaner to me, at this point, to go with a whole new name and not have to deal with the _possibility_ of something like this leading to confusion. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage--- [ This message is resent on behalf of David Wheeler [EMAIL PROTECTED]. -- justin ] On Monday, May 5, 2003, at 07:34 PM, Stas Bekman wrote: I don't think this will be robust enough, since vendors tend to do things in their own subtle ways. It's probably much better to explicitly search @INC, rather than relying on INSTALLVENDORARCH. Hrm, yes, I guess you're right. I was thinking that that would put it wherever mp1's make install put it, but vendors may have done all sorts of kookie things with it. p.s. the Apache/test.pm is quite big but should be ok if it's never be modified, which I hope is the case... Isn't Ken Williams the maintainer? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] ---End Message---
Re: resolving Apache::Test vs. Apache::test collision
---BeginMessage---
[ This message is resent on behalf of James G Smith [EMAIL PROTECTED].
-- justin ]
Stas Bekman [EMAIL PROTECTED] wrote:
We have a problem with using the Apache::Test name, more correctly we have a
problem with using the Apache/Test.pm filename. On platforms with
case-insentive filesystems (winFU, Mac OS X) if mod_perl 1.x is installed,
there is Apache/test.pm (notice the lower case 't'). So when you say 'use
Apache::Test' it loads Apache::test. Boom, nothing works.
There are several routes we can take to resolve this problem:
1. rename Apache::Test to something else. David Wheeler has proposed to use
Apache::Tester (or even swap the sides: Test::Apache).
As much work as it would require at this point (going through and
changing all the package names, renaming files, munging CVS), I think
Test::Apache would fit in better.
What convinced me of this was a look at my test code. At the top, ignoring
the code to test for availability, I basically have (under the new name):
use Test::Apache qw(plan have ok skip);
use Test::Apache::Request qw(GET);
plan tests = $some_number, have 'LWP';
# rest of tests here
__END__
In my non-Apache modules, I have:
use Test::More;
plan tests = $some_number;
# rest of tests here
__END__
There's a nice symmetry here.
Of course, I had to go and try combining the two :) They seem to
work. I am able to use Test::More to plan and report testing while I
use Apache::TestRequest to do the fetching. This undercuts a little
the argument for Test::Apache being the better name. We still need
the Apache::TestRequest version of GET because it knows where the
test server is.
use Test::More;
BEGIN {
eval {
require Apache::TestRequest;
Apache::TestRequest - import(qw(GET));
};
}
my @required = qw(
Apache::Test
Apache::TestRequest
DBD::CSV
HTML::Mason
LWP
);
my @unavailable;
if(@unavailable = grep { ! eval require $_ } @required) {
plan skip_all = The following modules are unavailable:
. join( , @unavailable);
exit 0;
}
plan tests = 1;
my $res = GET /mason/test1.html;
ok $res-content eq '[This is a Mason Page]
';
exit 0;
__END__
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
---End Message---
Re: can I help with docs?
On Tue, 27 May 2003 18:10:47 -0700 Jeremy Brown [EMAIL PROTECTED] wrote: [...] I found it pretty hard to configure flood with current documentation. I found some good examples with the package but nothing really covering conglomerates and other types of advanced setups. That might be just because conglomerates (and megaconglomerates) aren't implemented yet. They are a part of design, but right now topmost functional element is farm. There is a lot of stuff to sort out, so conglomerates and megaconglomerates won't happen any time soon. Can I help to write some documentation regarding it? Sure. I have figured out a few details and I can reference the code for more details. But is there anything that has been started with this information? There seems to be quite a bit of functionality that is missing from the current docs. Yes. This is mostly my fault. I've comitted few things without providing an example config how to use it (baseurl and auth support in particular). However I started writting real docs some time ago, sorting things out by using every information available (including cvs commit logs and such). I've picked up DocBook for the job. Mostly because there are some problems with integrating our docs with httpd-docs projects (I'll explain them later). It schould be however quite simple to migrate later from DocBook XML to httpd-docs XML. If you don't know DocBook, then write in plain text and I'll translate it to DocBook XML -- after all it's the content that matters. I'll publish all my work on homepage later this day, and post URL here, so others may also work on docs. As for commiting that stuff into CVS repo -- I would prefer to keep docs off httpd-test/flood repo for the time being. I remember the consensus was that we need to TR flood 1.1 (because flood-0.4 is buggy, and a lt of fixes went in since that release), but we need some real docs for that release. So after rolling flood 1.1 with docs, we can discuss where to put docs, what docs to put (XML or preprocessed HTML?) and discuss whole repo structure while we are at it :)) regards, Jacek Prucia
