Source Code Control and Naming ThingiePoo was Re: Starting Perl

[drieux]

On Thursday, Nov 13, 2003, at 10:34 US/Pacific, Chuk Goodin wrote:
[..]
Basically, if I've got a directory
sitting there with three or four different types of files in it, I'd 
like
to know which ones are perl (and I can just open them up in vi and fix
them) and which ones aren't (and I'll have to find the source 
somewhere if
I need to fix them).  Right now I use .pl for that.
[..]
Calling it a "process" is probably going too far.
[..]

You will forgive me if I whine a bit here,
first at the Unpleasant irony of 'organizational process'
as, well, .... yes, good quip.
So let us step back and look at the 'root cause problem'

	so I want to just 'fix it on the fly'

and yes, foo.pl as an editable text file will allow you
simply open it with a text editor and WHACK a fix in. Unlike
RealCode[tm] that has to be 'compiled' and installed. But
why not treat your 'perl code' like as if it were RealCode[tm]?
The code that makes it out onto the 'production machines' should
be treated with some respect, irregardless of the language used, eh no?
So why not start an 'organizational process' that begins with the

        this is our source code control system
        this is our build and release mechanism
        this is our installation mechanism
that type of process does not discriminate on the basis of
origins of source code. It likewise does not really care
much about the 'extensions' that may be 'fashionable', no?
Likewise it will help 'repeatability' and 'recoverability'
in the long run, since if you have your code under some form
of source code control, you can keep track of what got modified
by whom, and perchance why. You can also keep track of what is
'installed' - whether one is using the RPM information, or the
Solaris "Package Info", etc, etc, etc.
There is nothing quite as ugly as finding out that the only
copy of the foo code just got stomped on by an 'older version'
because, well, it was simpler to 'edit on the fly' the foo code,
because, well, it is just perl and it is editable, and it's not
like it was you know c-code or a RealCoding[tm] language...
If you back up your source tree, and cache it off site, then
one has the 'golden master' from which all can be rebuilt to
the current standard. In like manner, while at present you
may not see the usefulness of the POSIX style approach of /opt,
you may find that it will become useful for a variety of reasons
that lead to the creation and adoption of the 'standard'.
If you start this process early on, you CAN actually save yourself
much grief in the long run. ESPECIALLY when you start noticing that
there are common blocks of code in a bunch of *.pl files that could
be shifted into a common Our::Foo::Stuff perl module, and of course
at that point you want to be building it out with h2xs, so that you
can make the simpler process of having a Makefile created from the
Makefile.PL that will simplify installing the Perl Module in the
canonical CPAN style location so that all of the 'executables'
that are going to be delivered with it do not have to go gerryMeandering
around wondering where the Module got installed and can all start out
with that simple elegance of
        #!/usr/bin/perl -w
        use strict;
        use Our::Foo::Stuff;
        #------------------------------
        # this code does.....
        ....
Today it is one or two scripts, tomorrow you are up to your 
yaba-Hoo-Hoo-Hoo
trying to find all n-gagillion of them that all have the same common
defect because everyone opted to just fix it on the fly, and they
cut and pasted from one to the next, and there are cats and dogs
living together....

But by going back to the 'source' you get to edit in one fix,
crank the build and release handle that punks out one more
installable, and you haul it around, just like as if it were
RealCode[tm] and have some knowledge about what is installed where
and that your life is so much simpler.
ciao
drieux
---

ps: ok, if you name is Neo, going back to the Source
may make you twitch, but it is the right thing to do,
just get in touch with your inner, uh, correctness...


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]