On Tue, May 19, 2009 at 04:59:50PM -0700, Ask Bjørn Hansen wrote:
>> On May 19, 2009, at 7:22, Paul Johnson wrote:
>>> The way I do this is to build perl and all the modules I need on the
>> development machine. Then I package up the whole lot as a single
>> package.
>> The big failure in this is that you can only have "one version" of
> stuff. One developer experimentally wants to try a new version of
> Foo::Bar? Too bad. Want to deploy two versions of your app on the
> same box (prod/stage running as different users). Too bad. One
> developer debugging an older version of the application that a partner
> is using? Too bad.
>> Perl modules are part of your application; not of the system.
I'll admit that we're starting to get into "horses for courses"
territory here, but I think that this is where we are differing.
Not that I am fundamentally disagreeing with you, but I'm increasingly
coming to the opinion that if an application is important enough to care
about it's important to have its own environment. That could be a
dedicated box, a virtual machine, a zone, whatever. The important thing
is that you have the system tailored to your application and don't need
to worry about how that will affect other applications, since there are
none.
If an application is important then I don't want to have to make the
distinction between application and system. Neither do I, as a
developer, want to share my development system with anyone else in a way
that stops me doing whatever I want with it. (Terms and conditions
apply.)
Now, I'm sure with a little creativity and hand-wavy magic one could
arrange some such system in which applications and/or developers share
an environment, but I think I'd rather just fire up another virtual
machine. And in doing so, your concerns above are neatly sidestepped.
I'm not suggesting this is the correct approach for everyone - it's not
the approach I use for everything either - but it's an approach I like
when the application is important.
--
Paul Johnson - paul at pjcj.nethttp://www.pjcj.net