perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radoslaw Zielinski <ra...@karnet.pl>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Sun, 14 Nov 2004 14:51:09 GMT
Sorry for the delay, I couldn't make it sooner.

Stas Bekman <stas@stason.org> [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.

> 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.

>> * If the API wouldn't change, there would be no porting problems.  Even
>>   if mp2 is mostly backward-compatible, mp1 isn't forward-compatible; is
>>   it?  Now, there is no easy (automateable) way of discovering if the
>>   module works with mp1 or mp2, or for which version it was written for.
> 1) It should be documented.
> 2) It should be enforced at compile/run time.

In a perfect case.  But -- from my expirience -- it rarely is.

[...]
>> * "use Apache2" isn't mandatory, so (IIRC, when I checked last time)
>>   most of the mp-dependent code doesn't do it.  To patch, or not to
>>   patch?  To care, or to drop&forget?
> I know. I agree with that point. We have discussed that one quite a lot of 
> time. To sum up those discussions, the reason we don't load it 
> automatically is to let users adjust their @INC, before Apache2 is loaded. 
> Which is a must in case a user has a local modules installation and has 
> mod_perl2 living there.

> 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...?

>> * 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.

>> * Doug wrote: "xs modules will need Makefile.PL/#ifdef logic to work
>>   with both versions".  Well, from my expirience, if such a logic works
>>   in any not-so-weird case and doesn't require investigation / patching,
>>   it's accidental.  If you want both mp1 and mp2 on your system, you
>>   won't get away without all-the-hacks' know-how.
> From my personal experience, I have separate XS files for each version. 
> See Apache::Peek. I don't think it's a good idea to try to support both 
> versions in the same XS file. The C API is *totally* different between the 
> two generations.

I don't have any XS knowledge, so just guess it would be possible to
write separate "plugins" for both versions (if one wants to support
both).

[...]
>> All these issues boil down to one thing: you can't have mp1 and mp2 with
>> applications for both without using hacks.  You aimed for simplicity and
>> backward compatibility, but IMHO the result was reversed in this case.
> Either we are not on the same line or I'm not agreeing with you.

I think the first one.  We can eventually come back to it later.

> 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... :-/

> Granted, there are issues with making the process of choosing the right 
> generation (for those who have both installed) at build time. My hope 
> was/is to have one standard way to handle that.

IMHO sooner mp1 will vanish.

>> How could it be avoided?

>> 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.

> 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;

  $ cat MP2/compat1.pm 
  package MP2::compat1;
  use MP2::Foo;
  BEGIN { $INC{'MP1/Foo.pm'} = __FILE__; }
  *MP1::Foo::df = sub { print shift() . "::different_overridden\n"; };
  *MP1::Foo::sf = \&MP2::Foo::sf;
  1;

  $ perl -MMP2::compat1 -MMP1::Foo -we 'MP1::Foo->sf; MP1::Foo->df'
  MP1::Foo::same
  MP1::Foo::different_overridden

About [1]: if there is too many MP2::Foo's to use() them in MP2::compat1,
then maybe AutoLoader could help:

  $ cat MP2/compat1.pm 
  package MP2::compat1;
  use AutoLoader ();
  BEGIN { $INC{'MP1/Foo.pm'} = __FILE__; }
  *MP1::Foo::AUTOLOAD = \&MP2::compat1::autoload;
  sub autoload {
    ($AUTOLOAD =~ /^MP1::((.+)::.+)$/)
      ? eval "require MP2::$2"
      : die "you murderer, I didn't got here by accident";
    die $@ if $@;
    *MP1::Foo::df = sub { print shift() . "::different_overridden\n"; };
    *MP1::Foo::sf = \&MP2::Foo::sf;
    # other aliases go here... this should only be executed once
    goto &$AUTOLOAD;
  }
  1;

...well, maybe in a smarter way.  Note, that this allows coexistence of
both mp1 and mp2 applications in one interpreter.

[...]
> One more thing to consider. At the moment 3rd party modules will be 
> installed into Apache2/ if mp2 lives there. so if your proposal goes in, 
> that means that all CPAN modules will need to have Apache2/ for the mp2 
> implementation (in case there are two separate implementations) again 
> requiring a compat layer in the case where the user API of those CPAN 
> modules (not modperl) hasn't changed).

I think this price is worth the cleaner interface and less hackish
approach.

-- 
Radosław Zieliński <radek@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

Mime
View raw message