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

Jeff Chimene jchimene at gmail.com
Tue May 29 02:25:05 GMT 2007


Matt S Trout wrote:
> On Mon, May 28, 2007 at 05:20:04PM -0700, Jeff Chimene wrote:
>   
>> Matt S Trout wrote:
>>     
>>> On Mon, May 28, 2007 at 02:00:13PM -0700, Jeff Chimene wrote:
>>>       
>>>> 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.
>>     
>
> No, but I do have a fair bit of experience deploying software, and I'd strongly
> recommend against any deployment process that isn't as simple and repeatable
> as possible.
>
> Basically, an idempotent deployment process is almost always preferable where
> possible since it means you don't have to consider ordering problems - if
> a deployment fails part-way through you can simply re-run it, and if a system
> is "out of the loop" for a couple deployments (due to hardware failure, for
> e.g) you can still treat it identically to a machine on release N-1.
>
> I'm not on here to 'just answer your questions', I'm on here to be part of a
> community discussion list where we not only try and help people solve problems
> but to solve problems in -good- ways, especially since this list is archived
> and people use archive searches as a way to find ideas and implementation
> techniques - and as a member of the core team I try and make clear what I
> consider wise and unwise since I'm aware my choices often influence those
> of other Catalyst users. You are, of course, welcome to disagree with, argue
> against or ignore entirely any opinion I express but that's not going to stop
> me expressing them :)
>
>   
I don't have time to argue with you. You are not the arbiter of good or
bad development/deployment practices. I certainly will not be hiring you
for any projects.

Cheers,
jec



More information about the Catalyst mailing list