If your subroutine/method need objects/context associated with them
you could utilize the Plugin system to create your own plugin that
adds data/methods to $c
On Thu, Jul 14, 2016 at 11:52:39PM +0100, Andrew wrote:
> Okay, no worries, I've done it now.
>
> Created a folder called CommonUse to
a(s) a la(s) que va dirigida. Si usted lee este mensaje y no es el
> >destinatario señalado, el empleado o el agente responsable de entregar el
> >mensaje al destinatario, o ha recibido esta comunicación por error, le
> >informamos que está totalmente prohibida, y puede ser ilegal,
-i or whatever).
> 4. Make sure your PATH environment variables are set correctly.
>
> On Thu, Mar 3, 2016 at 7:23 AM, James Leu <j...@mindspring.com> wrote:
>
> > It all comes down to the apps 'environment`.
> >
> > Do you remember when you started developing
versions of modules
over time would still be needed.
On Wed, Mar 02, 2016 at 09:41:41PM +0100, Lasse Makholm wrote:
> On Wed, Mar 2, 2016 at 9:23 PM, James Leu <j...@mindspring.com> wrote:
>
> > It all comes down to the apps 'environment`.
> >
> > Do you remember wh
It all comes down to the apps 'environment`.
Do you remember when you started developing your catalyst app you had to
install a bunch of perl modules?
Those same modules (preferabbly the EXACT same versions as you installed
on your development machine) need to be installed on your
production
Just to add to Robert's idea.
We use perlbrew and Carton for our catalyst environments
We deploy via RPMs, but each RPM contains a perlprew environment
and a local lib dir managed by Carton.
On Wed, May 13, 2015 at 06:26:40PM +0100, Robert Brown wrote:
Not to answer your actual question, but...
question for the community here, what's your
deployment strategy, and why is it so?
What would you change if you're not the decision -maker.
On 13/05/15 21:58, James Leu wrote:
Just to add to Robert's idea.
We use perlbrew and Carton for our catalyst environments
We deploy via RPMs
