live and dev versions of a module on the same server

I'm trying to run both the live and dev versions of my website using virtual hosting in Apache 1.3, and using mod_perl 1.29 (on Debian stable, for reference).

The problem I'm having is that the package namespaces for the two handlers, and every module they require, clash. I might need different @INCs too. How have people got around this problem in the past?

Phil
--
() ASCII ribbon campaign () Hopeless ribbon campaign
/\ against HTML mail /\ against gratuitous bloodshed

[stolen with permission from Daniel B. Cristofani]

Re: live and dev versions of a module on the same server

Phil Carmody wrote:

> The problem I'm having is that the package namespaces for the two handlers, and every module they require, clash. I might need different @INCs too. How have people got around this problem in the past?

It's not a mod_perl problem. This is just how Perl works. You can't have 2 packages with the same
name. Period. Sometimes it's easy to think that Apache's VHosts are using different Perl
interpreters, but they aren't. Within the same process it's all the same interpreter.

So, if you want something similar to your original goal I see the following options:

1) Use a separate Apache. This isn't as hard as it sounds. And if you already have a proxy in front
(which you should) it's even easier. Just have some mod_redirect rules which send requests for your
dev version to a different port and have your other dev apache listening on that port. You don't
even need another machine.

2) Rename your dev module to something like Dev::OriginalModuleName. You could have some automated
scripts that process your dev code to remove these before sending it to production.

I like #1. I use it all the time for things like this and it works great. Complete separation
between the code. Since each Apache has a different @INC you can also do things like testing out
upgraded versions of CPAN modules, etc. I personally wouldn't do #2 since it means that the code you
test out isn't exactly the same code that you push to production. That would bother me.

--
Michael Peters
Plus Three, LP

Re: live and dev versions of a module on the same server

--- On Fri, 10/3/08, Phil Carmody wrote:

> From: Phil Carmody
> Subject: live and dev versions of a module on the same server
> To: modperl@perl.apache.org
> Date: Friday, October 3, 2008, 3:25 AM
> I'm trying to run both the live and dev versions of my
> website using virtual hosting in Apache 1.3, and using
> mod_perl 1.29 (on Debian stable, for reference).
>
> The problem I'm having is that the package namespaces
> for the two handlers, and every module they require, clash.
> I might need different @INCs too. How have people got around
> this problem in the past?
>
> Phil
> --
> () ASCII ribbon campaign () Hopeless ribbon
> campaign
> /\ against HTML mail /\ against
> gratuitous bloodshed
>
> [stolen with permission from Daniel B. Cristofani]


There are a few options:

1---
Run your VirtualHost with PerlOptions +Parent.
This gives each VirtualHost its own Perl interpreter.

2---
Run separate instances of Apache for each separate configuration setup you need.

3---
Instead of "use My::ModuleName;" do this:

# Delete the entry from %INC:
delete( $INC{'My/ModuleName.pm'} );

# Find and remove the @INC entry where the other module resides:
my $idx = 0;
$idx++ until $INC[$idx] eq '/path/to/wrong/lib';
splice(@INC, $idx, 1);

# Add the correct path to @INC:
unshift @INC, '/path/to/correct/lib';

# Now reload My::ModuleName:
require 'My/ModuleName.pm';
My::ModuleName->import();

That should force Perl to actually reload the module.

You could probably streamline this logic a little better as a subref inside of @INC.

Best regards,
John Drago

Re: live and dev versions of a module on the same server

Quoting John Drago :
>
> There are a few options:
>
> 1---
> Run your VirtualHost with PerlOptions +Parent.
> This gives each VirtualHost its own Perl interpreter.

This is mod_perl 2 specific, and until right now i personally was
completely unaware of it. Has anyone actually used it? Does it work
under all the MPM's?

Adam

Re: live and dev versions of a module on the same server

adam.prime@utoronto.ca wrote:
> Quoting John Drago :
>>
>> There are a few options:
>>
>> 1---
>> Run your VirtualHost with PerlOptions +Parent.
>> This gives each VirtualHost its own Perl interpreter.
>
> This is mod_perl 2 specific, and until right now i personally was
> completely unaware of it. Has anyone actually used it? Does it work
> under all the MPM's?

I've played with it and it works, but not in production or anything. I
think Torsten uses/used it.

Re: live and dev versions of a module on the same server

--- On Fri, 10/3/08, Michael Peters wrote:
> Phil Carmody wrote:
> > The problem I'm having is that the package
> > namespaces for the two handlers, and every module they
> > require, clash. I might need different @INCs too. How have
> > people got around this problem in the past?
>
> It's not a mod_perl problem. This is just how Perl
> works. You can't have 2 packages with the same
> name. Period. Sometimes it's easy to think that
> Apache's VHosts are using different Perl
> interpreters, but they aren't. Within the same process
> it's all the same interpreter.

I presume that all hosting services which offer LAMP do so via virtual machines then, or via Apache 2. That might make my "how to go live" decisions trickier for other projects which I'm not prepared to host on my home machine.

> So, if you want something similar to your original goal I
> see the following options:
>
> 1) Use a separate Apache. This isn't as hard as it
> sounds. And if you already have a proxy in front
> (which you should) it's even easier. Just have some
> mod_redirect rules which send requests for your
> dev version to a different port and have your other dev
> apache listening on that port. You don't
> even need another machine.

After working out that I was never going sensibly going to be able to get the modules to name themselves on the fly (physically possible, but probably slower and definitely uglier code) that's what I aimed for post haste. It was basically a complete piece of cake. The extra benefit of this is that I can stop and start the dev server without any interruptions to the several other vhosts that I run on the live server. I'm not bothering with init.d, it's very easy to start and stop a second apache by hand. As it exists _only_ to serve one mod_perl handler, it doesn't need to be configured to do anything else, translate anything, rewrite anything, or index anything, so the new http.conf is trivial to create.

Many thanks for confirming that.
Phil

Re: live and dev versions of a module on the same server

On Fri, Oct 3, 2008 at 4:25 PM, Phil Carmody wrote:
> I presume that all hosting services which offer LAMP do so via virtual machines then, or via Apache 2.

No, they typically just offer CGI. This is not an issue with CGI
because you're spawning a whole new Perl interpreter for every
request. For mod_perl or FastCGI you need to use one of the
suggestions in this thread.

- Perrin

Re: live and dev versions of a module on the same server

"Perrin Harkins" writes:

> On Fri, Oct 3, 2008 at 4:25 PM, Phil Carmody wrote:
>> I presume that all hosting services which offer LAMP do so via virtual machines then, or via Apache 2.
>
> No, they typically just offer CGI. This is not an issue with CGI
> because you're spawning a whole new Perl interpreter for every
> request. For mod_perl or FastCGI you need to use one of the
> suggestions in this thread.

And the interesting thing about CGI and mod_perl being basically
independent is that running your development code as a CGI script is a
great way to test it. I write my code using CGI.pm, which will use
mod_perl if it's run under mod_perl, or act as a regular CGI script if
it is not. If the development version of my script is run, it adds
the development library path to @INC (with "use lib"); otherwise it
adds the production library path. Between those two things I get a
development environment which is basically seperate from my production
environment, although it is much slower. I have had very good luck
with this approach.

Still, I keep another Apache instance around to do the final testing.
That's useful too, especially on the rare occasion that the behavior
is different.

----Scott.