[Catalyst] Requirement for Makfile.PL or Build.PL in "home"?

[Jeff Chimene]

Matt S Trout wrote:
> On Mon, May 28, 2007 at 02:00:13PM -0700, Jeff Chimene wrote:
>   
>> Matt S Trout wrote:
>>     
>>> On Mon, May 28, 2007 at 12:11:54PM -0700, Jeff Chimene wrote:
>>>   
>>>       
>>>> In Catalyst::Utils::home
>>>> is the following requirement documented anywhere?
>>>> # only return the dir if it has a Makefile.PL or Build.PL
>>>> if (-f $home->file("Makefile.PL") or -f $home->file("Build.PL"))
>>>>     
>>>>         
>>> It's only required if you haven't installed the app - it's how Catalyst tells
>>> you're still running out of a development directory.
>>>
>>>   
>>>       
>> What does "installed the app..." mean?
>>     
>
> perl Makefile.PL; make install
>   
OK. I hadn't considered putting the Perl files into the shared
directories on the server. I know there are settings that one can enable
to force the installation to a user-specific directory tree. Since I'm
chasing installation problems w/r/t/ configuration differences between
the development & production machines, this is one more item to learn
that only incrementally adds value.
>  
>   
>> The use case is that I copied all files in the HOME & descendants (but
>> Makefile.PL and Build.PL) to the production machine. Two hours later, I
>> figured out why the app wouldn't start. Hence this topic.
>>     
>
> How do you verify your production machine has any new dependencies without
> Makefile.PL ?
>
>   
It isn't that complicated a deployment.
>> P.S. I originally sent this app to the server via Makefile.PL
>> constructing a tarball. The disadvantage is that this is a crappy way to
>> send .PATCH files; which process is how I'd like to move from
>> development to production in this Brave New World after the initial
>> deployment. Of course, it turns out that the production machine doesn't
>> have /usr/bin/patch, but that's another issue.
>>     
>
> That's a really, spectacularly bad idea since it means your deployment process
> isn't repeatable, which makes it a crappy deployment process :)
>   
You aren't the arbiter of what's good or bad. Please just answer my
questions, reserving your opinions for beer-thirty.

Cheers,
jec