You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Ali ISIK <fe...@gmail.com> on 2006/11/06 16:01:28 UTC
[mp2] PAR in production?
Hi there, folks -- is the use of PAR with mp2
recommended in production? We are considering
distribution options for an mp2 application, including
vmware and rPath, which can be rather expensive,
depending on your targeted market segment. Is there
any consensus on this issue, any "standard"
recommendation among the wise/experienced mp
developers and admins? How have you, for instance,
distributed your last application and how do you rate
the experience?
--Ali Isik
Re: [mp2] PAR in production?
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2006-11-09 at 11:10 -0800, Fred Moyer wrote:
> Have you found a way
> of shipping a custom perl build in addition to all the other components?
I don't think it would be hard to do, but perl takes so long to compile
that most people would object.
- Perrin
Re: [mp2] PAR in production?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Not Sophos. ActivePerl.
ActivePerl costs $0.00 to download and use, but AFAIK it's not "free
software", thus the question :-)
Issac
Frank Wiles wrote:
> On Wed, 15 Nov 2006 12:34:50 +0200
> Issac Goldstand <ma...@beamartyr.net> wrote:
>
>> Cool!
>>
>> But, what license does it have?
>
> Sophos is a commercial product.
>
> ---------------------------------
> Frank Wiles <fr...@wiles.org>
> http://www.wiles.org
> ---------------------------------
>
>
>> Foo JH wrote:
>>> Are you guys referring to this tool ActiveState released for
>>> relocating Perl:
>>> http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/site/lib/ActiveState/RelocateTree.html
>>>
>>>
>>>
>>> Frank Wiles wrote:
>>>> On Mon, 13 Nov 2006 10:24:21 +0200
>>>> Issac Goldstand <ma...@beamartyr.net> wrote:
>>>>
>>>>
>>>>> Frank Wiles wrote:
>>>>>
>>>>>> I believe this is how Sophos' PureMessage installs itself.
>>>>>> Basically putting your own Perl binary and module paths in
>>>>>> say /usr/local/myapp/bin/perl. This is probably the best way
>>>>>> to ensure you have full control over everything about your
>>>>>> application.
>>>>> I actually imagine that Sophos does it exactly the same way
>>>>> ActivePerl does it; until recently they owned ActiveState, and
>>>>> thus had access to the ActivePerl setup scripts :-)
>>>>>
>>>> hehe good point! :)
>>>>
>>>>> FYI, it's not just @INC and binary - there are also changes
>>>>> needed, for example, in Config.pm, or you won't be able to
>>>>> install new modules to your new perl site...
>>>>>
>>>> What I meant was build a custom Perl with say
>>>> --prefix=/usr/local/myapp, install all of your modules with it,
>>>> and reproduce the entire structure with your packager ( for example
>>>> RPM ).
>>>> Most apps that are after this sort of setup aren't interested
>>>> in allowing the user to install new modules, they specifically want
>>>> to control the entire environment to avoid version bugs and
>>>> support issues.
>>>> ---------------------------------
>>>> Frank Wiles <fr...@wiles.org>
>>>> http://www.wiles.org
>>>> ---------------------------------
>>>>
>>>>
>
Re: [mp2] PAR in production?
Posted by Frank Wiles <fr...@wiles.org>.
On Wed, 15 Nov 2006 12:34:50 +0200
Issac Goldstand <ma...@beamartyr.net> wrote:
> Cool!
>
> But, what license does it have?
Sophos is a commercial product.
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------
>
> Foo JH wrote:
> > Are you guys referring to this tool ActiveState released for
> > relocating Perl:
> > http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/site/lib/ActiveState/RelocateTree.html
> >
> >
> >
> > Frank Wiles wrote:
> >> On Mon, 13 Nov 2006 10:24:21 +0200
> >> Issac Goldstand <ma...@beamartyr.net> wrote:
> >>
> >>
> >>> Frank Wiles wrote:
> >>>
> >>>> I believe this is how Sophos' PureMessage installs itself.
> >>>> Basically putting your own Perl binary and module paths in
> >>>> say /usr/local/myapp/bin/perl. This is probably the best way
> >>>> to ensure you have full control over everything about your
> >>>> application.
> >>> I actually imagine that Sophos does it exactly the same way
> >>> ActivePerl does it; until recently they owned ActiveState, and
> >>> thus had access to the ActivePerl setup scripts :-)
> >>>
> >>
> >> hehe good point! :)
> >>
> >>> FYI, it's not just @INC and binary - there are also changes
> >>> needed, for example, in Config.pm, or you won't be able to
> >>> install new modules to your new perl site...
> >>>
> >>
> >> What I meant was build a custom Perl with say
> >> --prefix=/usr/local/myapp, install all of your modules with it,
> >> and reproduce the entire structure with your packager ( for example
> >> RPM ).
> >> Most apps that are after this sort of setup aren't interested
> >> in allowing the user to install new modules, they specifically want
> >> to control the entire environment to avoid version bugs and
> >> support issues.
> >> ---------------------------------
> >> Frank Wiles <fr...@wiles.org>
> >> http://www.wiles.org
> >> ---------------------------------
> >>
> >>
Re: [mp2] PAR in production?
Posted by Foo JH <jh...@extracktor.com>.
Depends if you plan to make money out of it. Otherwise iirc it doesn't
cost you a cent.
Issac Goldstand wrote:
> Cool!
>
> But, what license does it have?
>
> Foo JH wrote:
>> Are you guys referring to this tool ActiveState released for
>> relocating Perl:
>> http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/site/lib/ActiveState/RelocateTree.html
>>
>>
>>
>> Frank Wiles wrote:
>>> On Mon, 13 Nov 2006 10:24:21 +0200
>>> Issac Goldstand <ma...@beamartyr.net> wrote:
>>>
>>>
>>>> Frank Wiles wrote:
>>>>
>>>>> I believe this is how Sophos' PureMessage installs itself.
>>>>> Basically putting your own Perl binary and module paths in
>>>>> say /usr/local/myapp/bin/perl. This is probably the best way
>>>>> to ensure you have full control over everything about your
>>>>> application.
>>>> I actually imagine that Sophos does it exactly the same way
>>>> ActivePerl does it; until recently they owned ActiveState, and thus
>>>> had access to the ActivePerl setup scripts :-)
>>>>
>>>
>>> hehe good point! :)
>>>> FYI, it's not just @INC and binary - there are also changes needed,
>>>> for example, in Config.pm, or you won't be able to install new
>>>> modules to your new perl site...
>>>>
>>>
>>> What I meant was build a custom Perl with say
>>> --prefix=/usr/local/myapp, install all of your modules with it, and
>>> reproduce the entire structure with your packager ( for example
>>> RPM ).
>>> Most apps that are after this sort of setup aren't interested in
>>> allowing the user to install new modules, they specifically want
>>> to control the entire environment to avoid version bugs and
>>> support issues.
>>> ---------------------------------
>>> Frank Wiles <fr...@wiles.org>
>>> http://www.wiles.org
>>> ---------------------------------
>>>
>>>
Re: [mp2] PAR in production?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Cool!
But, what license does it have?
Foo JH wrote:
> Are you guys referring to this tool ActiveState released for
> relocating Perl:
> http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/site/lib/ActiveState/RelocateTree.html
>
>
>
> Frank Wiles wrote:
>> On Mon, 13 Nov 2006 10:24:21 +0200
>> Issac Goldstand <ma...@beamartyr.net> wrote:
>>
>>
>>> Frank Wiles wrote:
>>>
>>>> I believe this is how Sophos' PureMessage installs itself.
>>>> Basically putting your own Perl binary and module paths in
>>>> say /usr/local/myapp/bin/perl. This is probably the best way to
>>>> ensure you have full control over everything about your
>>>> application.
>>> I actually imagine that Sophos does it exactly the same way
>>> ActivePerl does it; until recently they owned ActiveState, and thus
>>> had access to the ActivePerl setup scripts :-)
>>>
>>
>> hehe good point! :)
>>
>>> FYI, it's not just @INC and binary - there are also changes needed,
>>> for example, in Config.pm, or you won't be able to install new
>>> modules to your new perl site...
>>>
>>
>> What I meant was build a custom Perl with say
>> --prefix=/usr/local/myapp, install all of your modules with it, and
>> reproduce the entire structure with your packager ( for example
>> RPM ).
>> Most apps that are after this sort of setup aren't interested in
>> allowing the user to install new modules, they specifically want
>> to control the entire environment to avoid version bugs and
>> support issues.
>> ---------------------------------
>> Frank Wiles <fr...@wiles.org>
>> http://www.wiles.org
>> ---------------------------------
>>
>>
Re: [mp2] PAR in production?
Posted by Foo JH <jh...@extracktor.com>.
Are you guys referring to this tool ActiveState released for relocating
Perl:
http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/site/lib/ActiveState/RelocateTree.html
Frank Wiles wrote:
> On Mon, 13 Nov 2006 10:24:21 +0200
> Issac Goldstand <ma...@beamartyr.net> wrote:
>
>
>> Frank Wiles wrote:
>>
>>> I believe this is how Sophos' PureMessage installs itself.
>>> Basically putting your own Perl binary and module paths in
>>> say /usr/local/myapp/bin/perl. This is probably the best way to
>>> ensure you have full control over everything about your
>>> application.
>>>
>> I actually imagine that Sophos does it exactly the same way
>> ActivePerl does it; until recently they owned ActiveState, and thus
>> had access to the ActivePerl setup scripts :-)
>>
>
> hehe good point! :)
>
>
>> FYI, it's not just @INC and binary - there are also changes needed,
>> for example, in Config.pm, or you won't be able to install new
>> modules to your new perl site...
>>
>
> What I meant was build a custom Perl with say
> --prefix=/usr/local/myapp, install all of your modules with it, and
> reproduce the entire structure with your packager ( for example
> RPM ).
>
> Most apps that are after this sort of setup aren't interested in
> allowing the user to install new modules, they specifically want
> to control the entire environment to avoid version bugs and
> support issues.
>
> ---------------------------------
> Frank Wiles <fr...@wiles.org>
> http://www.wiles.org
> ---------------------------------
>
>
Re: [mp2] PAR in production?
Posted by Frank Wiles <fr...@wiles.org>.
On Mon, 13 Nov 2006 10:24:21 +0200
Issac Goldstand <ma...@beamartyr.net> wrote:
> Frank Wiles wrote:
> > I believe this is how Sophos' PureMessage installs itself.
> > Basically putting your own Perl binary and module paths in
> > say /usr/local/myapp/bin/perl. This is probably the best way to
> > ensure you have full control over everything about your
> > application.
>
> I actually imagine that Sophos does it exactly the same way
> ActivePerl does it; until recently they owned ActiveState, and thus
> had access to the ActivePerl setup scripts :-)
hehe good point! :)
> FYI, it's not just @INC and binary - there are also changes needed,
> for example, in Config.pm, or you won't be able to install new
> modules to your new perl site...
What I meant was build a custom Perl with say
--prefix=/usr/local/myapp, install all of your modules with it, and
reproduce the entire structure with your packager ( for example
RPM ).
Most apps that are after this sort of setup aren't interested in
allowing the user to install new modules, they specifically want
to control the entire environment to avoid version bugs and
support issues.
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------
Re: [mp2] PAR in production?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Frank Wiles wrote:
> I believe this is how Sophos' PureMessage installs itself. Basically
> putting your own Perl binary and module paths in
> say /usr/local/myapp/bin/perl. This is probably the best way to
> ensure you have full control over everything about your application.
>
I actually imagine that Sophos does it exactly the same way ActivePerl
does it; until recently they owned ActiveState, and thus had access to
the ActivePerl setup scripts :-)
FYI, it's not just @INC and binary - there are also changes needed, for
example, in Config.pm, or you won't be able to install new modules to
your new perl site...
Issac
Re: [mp2] PAR in production?
Posted by Frank Wiles <fr...@wiles.org>.
On Thu, 9 Nov 2006 11:10:24 -0800 (PST)
Fred Moyer <fr...@redhotpenguin.com> wrote:
> On Wed, 8 Nov 2006, Perrin Harkins wrote:
> > On Mon, 2006-11-06 at 12:28 -0600, Frank Wiles wrote:
> >> What I have always done is package my applications as if they
> >> are CPAN modules using ExtUtils::MakeMaker or in more recent
> >> days Module::Build. Never had a problem with it, but it probably
> >> isn't suited to distributing apps to novice users.
> >
> > We do the same sort of thing here, with an automated build script
> > that builds apache, mod_perl, and our modules from source. You can
> > see some work on generalizing that for others to use here:
> > http://sourceforge.net/projects/matchstick
>
> I like this approach, but it still requires a perl binary to make
> everything happen. The default perl compile on a lot of systems out
> there is threaded, and built for general use. Have you found a way
> of shipping a custom perl build in addition to all the other
> components?
>
> Over a year ago I wrote a variation on what you described, but
> additionally it bootstrapped perl from source, then build apache,
> mod_perl, and the modules. Bootstrapping perl from source was
> troublesome, and generally sucked - everything else worked fairly
> well. I've been experimenting with building a perl rpm for redhat,
> but I've found that to be less than painless to build one that
> provides a second binary in addition to the system binary. Any
> thoughts?
Look at the code for SqueezeBox at slimdevices.com. It's not
only a great product, but they have some pretty decent packaging
for Windows, Mac, and Linux. While they don't send a custom
Perl with it, they do send some custom modules and modify @INC
to make sure you use their versions of certain CPAN modules.
But in any case, with a decent packaging system ( outside of
Perl's I would wager ) it wouldn't be hard to build a Perl for each
of your target platforms, include it in your package, and then make
sure all of your code references that special Perl.
I believe this is how Sophos' PureMessage installs itself. Basically
putting your own Perl binary and module paths in
say /usr/local/myapp/bin/perl. This is probably the best way to
ensure you have full control over everything about your application.
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------
Re: [mp2] PAR in production?
Posted by Michael Peters <mp...@plusthree.com>.
Foo JH wrote:
> I don't understand. What do you mean by 'perl is not relocatable'? I've
> put (Active)Perl in the same directory as the apache server in a
> copy-paste operation. But this is in Windows.
One example is that @INC is determined at compile time. If you move your perl
around, @INC doesn't change. Having it be truly relocatable means that the
binary can find libraries relative to it's installation rather than being a full
path.
After reading some archives it seems that ActivePerl may already be able to do
this, but I'm not sure.
--
Michael Peters
Developer
Plus Three, LP
Re: [mp2] PAR in production?
Posted by Foo JH <jh...@extracktor.com>.
I don't understand. What do you mean by 'perl is not relocatable'? I've
put (Active)Perl in the same directory as the apache server in a
copy-paste operation. But this is in Windows.
Michael Peters wrote:
> Fred Moyer wrote:
>
>
>> I like this approach, but it still requires a perl binary to make
>> everything happen. The default perl compile on a lot of systems out
>> there is threaded, and built for general use. Have you found a way of
>> shipping a custom perl build in addition to all the other components?
>>
>
> It's problematic because perl is not relocatable. But Nicolas Clark's work will
> make 5.10 relocatable and thus possible to bundle a custom build of perl with
> the application.
>
>
Re: [mp2] PAR in production?
Posted by Michael Peters <mp...@plusthree.com>.
Fred Moyer wrote:
> I like this approach, but it still requires a perl binary to make
> everything happen. The default perl compile on a lot of systems out
> there is threaded, and built for general use. Have you found a way of
> shipping a custom perl build in addition to all the other components?
It's problematic because perl is not relocatable. But Nicolas Clark's work will
make 5.10 relocatable and thus possible to bundle a custom build of perl with
the application.
--
Michael Peters
Developer
Plus Three, LP
Re: [mp2] PAR in production?
Posted by Fred Moyer <fr...@redhotpenguin.com>.
On Wed, 8 Nov 2006, Perrin Harkins wrote:
> On Mon, 2006-11-06 at 12:28 -0600, Frank Wiles wrote:
>> What I have always done is package my applications as if they
>> are CPAN modules using ExtUtils::MakeMaker or in more recent
>> days Module::Build. Never had a problem with it, but it probably
>> isn't suited to distributing apps to novice users.
>
> We do the same sort of thing here, with an automated build script that
> builds apache, mod_perl, and our modules from source. You can see some
> work on generalizing that for others to use here:
> http://sourceforge.net/projects/matchstick
I like this approach, but it still requires a perl binary to make
everything happen. The default perl compile on a lot of systems out there
is threaded, and built for general use. Have you found a way
of shipping a custom perl build in addition to all the other components?
Over a year ago I wrote a variation on what you described, but
additionally it bootstrapped perl from source, then build apache, mod_perl,
and the modules. Bootstrapping perl from source was troublesome, and
generally sucked - everything else worked fairly well. I've been
experimenting with building a perl rpm for redhat, but I've found that to
be less than painless to build one that provides a second binary in
addition to the system binary. Any thoughts?
Re: [mp2] PAR in production?
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2006-11-06 at 12:28 -0600, Frank Wiles wrote:
> What I have always done is package my applications as if they
> are CPAN modules using ExtUtils::MakeMaker or in more recent
> days Module::Build. Never had a problem with it, but it probably
> isn't suited to distributing apps to novice users.
We do the same sort of thing here, with an automated build script that
builds apache, mod_perl, and our modules from source. You can see some
work on generalizing that for others to use here:
http://sourceforge.net/projects/matchstick
- Perrin
Re: [mp2] PAR in production?
Posted by Frank Wiles <fr...@wiles.org>.
On Mon, 6 Nov 2006 17:01:28 +0200
"Ali ISIK" <fe...@gmail.com> wrote:
> Hi there, folks -- is the use of PAR with mp2
> recommended in production? We are considering
> distribution options for an mp2 application, including
> vmware and rPath, which can be rather expensive,
> depending on your targeted market segment. Is there
> any consensus on this issue, any "standard"
> recommendation among the wise/experienced mp
> developers and admins? How have you, for instance,
> distributed your last application and how do you rate
> the experience?
I've been thinking about using PAR, ( specifically Apache::PAR )
for distributing applications for awhile. However, I just noticed
that the current version on CPAN doesn't support MP2. It wouldn't
be difficult to patch however, looks like it hasn't been updated
since the big mp2 API change.
What I have always done is package my applications as if they
are CPAN modules using ExtUtils::MakeMaker or in more recent
days Module::Build. Never had a problem with it, but it probably
isn't suited to distributing apps to novice users.
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------
Re: [mp2] PAR in production?
Posted by Foo JH <jh...@extracktor.com>.
I've tried using Apache::PAR, but I think it needs some work to get it
working on MP2 or MP2.2. There is a lazy way to go about it:
1. In your httpd.conf insert:
PerlRequire startup.pl
2. In your startup.pl load your PAR files.
Hope this helps.
Ali ISIK wrote:
> Hi there, folks -- is the use of PAR with mp2
> recommended in production? We are considering
> distribution options for an mp2 application, including
> vmware and rPath, which can be rather expensive,
> depending on your targeted market segment. Is there
> any consensus on this issue, any "standard"
> recommendation among the wise/experienced mp
> developers and admins? How have you, for instance,
> distributed your last application and how do you rate
> the experience?
>
> --Ali Isik