Sorry for the delay, I couldn't make it sooner.
Stas Bekman <[EMAIL PROTECTED]> [03-11-2004 02:30]:
Radoslaw Zielinski wrote:
[...]
* It messes with @INC, changing the way it should be parsed. Originally, if you see $inc_file/Foo/Bar/Baz.pm, you know it's the Foo::Bar::Baz perl module. Now, it's Foo::Bar::Baz *unless* Foo equals to Apache2. The only other module I know, which does it, is Tk; it creates problems with automated dependency generators (at least), besides being a hack.
it doesn't.
Well, it (the MP_INST_APACHE2 hack) does: "use Apache2" adds an entry to @INC and other modules rely on it.
When saying "it doesn't" I was talking about the para below:
There is no Apache2::Apache::Server. There is Apache::Server. It's just one Apache2/ subdir (like there are many other special subdirs in @INC dirs). Shouldn't be too hard to get used to it.
I don't know of any more but Tk's plugin directory.
Think user-installed local modules under ~foo/lib/perl
This whole issue is moot for users who have moved to mp2 and forgot that mp1 ever existed, which will be the case for 99% of users some time after 2.0 is released and considered stable.
And what should an average Joe Distributor do while both versions are in use...?
Good point. In which case mp2 will always have to go to Apache2/.
* A sysadmin (or user) without Perl knowledge won't even be able to build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for example), when an installation of mp1 already exists -- requires ripping Makefile.PL with sharpened $EDITOR. Yes, this Makefile.PL can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one of many.
I'm not following you on this one. What's the problem of passing MP_INST_APACHE2=1? You mean they actually need to know that they need to type that? But the error message tells them that already.
No. Maybe a "patch" will show it:
--- mod_perl-1.99_15-org/Makefile.PL 2004-08-24 18:33:21.035839248 +0200 +++ mod_perl-1.99_13/Makefile.PL 2004-08-24 18:34:24.406205488 +0200 @@ -151,7 +151,7 @@ error "cannot install mod_perl/$VERSION on top of $vstring", "use MP_INST_APACHE2=1 option " . "or to force installation delete:\n $old_modperl_pm"; - exit 1; +# exit 1; } } }
I want to build without MP_INST_APACHE2 and run make install with DESTDIR. This is a minor example of problems with "Makefile.PL logic". Nevermind.
Good point again. We should support that. i.e. if DESTDIR is specified we shouldn't enforce MP_INST_APACHE2=1 unless we find mod_perl 1 installed at that DESTDIR.
There are quite a few CPAN modules that deploy that technique. e.g. Apache-VMonitor-2.0.
It uses a 5KB Makefile.PL just for figuring the installation path and dependencies... :-/
True. My idea was to write a helper module and make it available on CPAN, so all other 3rd party modules can use that and have very simple Makefile.PL files. Notice that it also requires special arguments passed to Makefile.PL to handle the situation when both mp1 and mp2 are installed. So if the same API is not embraced by all other 3rd party modules it's going to be a pain.
Full Apache2::* namespace. Apache2::compat::Apache1 could provide Apache::*->Apache2::* aliases for compatible features and define custom Apache::* for the incompatible ones -- both types of applications could work in one interpreter. That would leave place for A2::compat::A3, and maybe for Apache::compat::Apache2. No hacks required.
If you dig under the hood, it's not simple at all. To start with how are you going to handle the fact that no module is loaded by default? And you certainly don't want to load 50 modules each coming with .so object, just
[1]
to support this aliasing feature. Or do you suggest to just alias the namespaces?
Maybe I'm missing something. I was thinking about just aliasing the namespaces.
It's a way more complicated than it seems to be at first sight. Search the dev list's archives for EazyLife to see some of the problems.
Second, quite a few methods have the same API name, but a totally different functionality. Please see lib/Apache/compat.pm starting from overridable_mp2_api.
I can't see how the two can coexist.
$ cat MP2/Foo.pm package MP2::Foo;
sub sf { print shift() . "::same\n"; }
sub df { print shift() . "::different\n"; }
1;
[...] > ...well, maybe in a smarter way. Note, that this allows coexistence of > both mp1 and mp2 applications in one interpreter.
The problem is that mp1 and mp2 aren't fully compatible, and there is no way to make them so 100%, mainly. So you have a problem here. You can't run all mp1 and mp2 applications under the same interpreter. Again take a look at lib/Apache/compat.pm %overridable_mp2_api and read:
http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
I think I've mentioned this already, I'm not disagreeing with you, Radoslaw, that I've wished there was a better way than what we have now. But if you really start implementing your proposal you will see that there are problems in your idea. And some of them might be the showstopper. You are more than welcome to prove me/us wrong with a concrete working code.
-- __________________________________________________________________ Stas Bekman JAm_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]
