Re: Programming Department

One thing most people overlook, that I find extremely useful is to build EVERY application or library as if you were going to release it to CPAN. This has several advantages and takes almost no extra time once you get used to it. The main advantages are:

You can leverage the existing install infrastructure to automatically handle dependicies for you.
In your dist you can hold all of our associated documentation, database schemas, cron scripts, etc. all in one tar.gz.
As one of my co-workers just started us using, you can use CPAN::Mini to help install applications and/or libraries on multiple servers easily.
It makes each app consistent. You know what you'll find in bin/, in docs/, in sql/, in lib/... no surprises and it makes the programmer who has to maintain your code a year from now ( which is btw most likely you! ) have a much easier job.

Take a typical web app, you've got your Perl code, your database schema, your configuration information, and probably at least a few cron scripts.

By using something like module-starter and Module::Build you can automatically install your templates in say /usr/share/web-templates, your cron scripts into /opt/app/cron/, and drop your configuration into /etc/httpd/conf.d with a simple make install

If you aren't familiar with either Module::Build or ExtUtils::MakeMaker then there is a bit of a learning curve, but once you learn how to use these modules effectively, doing this adds a very trivial amount of time to each app and/or library. Trust me that once you start using it, you'll never want to work in an environment that doesn't.

Frank Wiles <frank@wiles.org>
http://www.wiles.org
http://www.revsys.com

Comment on Re: Programming Department

Replies are listed 'Best First'.
Re^2: Programming Department by BrowserUk (Patriarch) on Jan 14, 2006 at 23:41 UTC
Conversely, if you have no intentions of releasing your code to CPAN, you may decide to avoid the nightmare of the unnecessary, undocumented, unarchitected, unfathomable, unmaintainable, over-elaborate, rotting festering mess that is ExeUtils::MakeMaker completely. And for anything you do have a hankering to release to CPAN, spend an hour or two trying to understand what the hell is going on when you run the Makefile.pl for any moderately complex CPAN module, and try to imagine the trouble you are going to have to incorporate any extra customs steps. For example, say you would rather have your build process extract the files directly from your source code repository? Rather than having to do this as an extra manual step, with the inherent weakness of forcing the duplication of your source tree and/or imposing the convoluted pattern that is the 'blib' phenomena upon your source tree structure. Look hard and think very carefully how you would modify EU::MM to do this? Of course, I (infamously) do not have any CPAN modules to my credit, so I may be just crying wolf, so I urge you to look at and think about the problems this route would cause you. Also, take a look around at some of the comments made about the ExtUtils::MakeMaker module by it's current maintainer. And if the Module::Build route looks interesting, have a good look around at the internecine struggle between it's proponents and the EU::MM diehards. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^3: Programming Department by Aristotle (Chancellor) on Jan 15, 2006 at 01:50 UTC
I find the typical Module::Build opponent’s argument that it’s not mature and won’t be for a long time to be quite disingenious. Only software which has users improves. The argument that you inflict pain on users is understandable, but for simple needs you can avoid that by way of `create_makefile_pl => 'traditional'`. And while users complain that there is no compatible `PREFIX` support, I always found it a mess to deal with as a user and applaud the coming of `install_base`. The other option is Module::Install, which for some reason I can’t bring myself to like, even though everyone using it seems to rave about it. Last I looked, I couldn’t find much documentation, anyway. Makeshifts last the longest.	[reply] [d/l] [select]
Re^4: Programming Department by adamk (Chaplain) on Jan 15, 2006 at 05:44 UTC
Try clicking on the link to Module::Install you just created... there's been a total overhaul of the documentation in the last few weeks. (still more to go, spelling and grammar etc) Proper SYNOPSIS, a list of the commands, cookbook stuff... is there anything you feel is still missing?	[reply]
Re^3: Programming Department by adamk (Chaplain) on Jan 15, 2006 at 05:51 UTC
Yes, you're crying wolf. Forget EU::MM and Module::Build and just use Module::Install, which wraps BOTH of them as needed and makes writing installers almost trivial. http://search.cpan.org/src/ADAMK/PPI-1.109/Makefile.PL You example is bizarre... you only need to store the actual modules, the blib stuff (which is used for compiling and so on) only exists between when you run Makefile.PL and when you run make install. It never goes anywhere near the repository As for doing things from the repository, we just use... `svn checkout http://..../project cd project perl Makefile.PL make make test make install` [download]	[reply] [d/l]
Re^4: Programming Department by BrowserUk (Patriarch) on Jan 15, 2006 at 06:23 UTC
and makes writing installers almost trivial. And why on earth would the OP want to "write installers" for internal code development? Please go back to the top of the thread and read the context in which my post was made. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^5: Programming Department by pileofrogs (Priest) on Jan 15, 2006 at 07:21 UTC
Re^5: Programming Department by Aristotle (Chancellor) on Jan 16, 2006 at 06:35 UTC
Re^6: Programming Department by BrowserUk (Patriarch) on Jan 16, 2006 at 08:06 UTC
Some notes below your chosen depth have not been shown here
Re^3: Programming Department by ides (Deacon) on Jan 15, 2006 at 16:44 UTC
My intent wasn't to promote ExtUtils::MakeMaker, I too have found it hard to work with for complex tasks, which is why I now use Module::Build and am going to be taking a hard look at Module::Install in the near future. I also think you misunderstood most of my post. There is no duplication of your source tree, and no blib weirdness. Your source repository for a particular app *IS* your build environment. There is no need to have your build process checkout the source, your simply build a dist in your working copy. To give a detailed example let's say I have a mod_perl application that I'm building called 'Foo'. I start off my application with module-starter and it creates the Foo/ tree for me with a lib/ ( where your code goes ) and the other various elements we're all accustomed to. Once I've put in stubs for all of my various modules, Foo::Main, Foo::Admin::*, Foo::Model, etc... I then check this entire structure into my revision control system ( I use subversion ) and I'm done. No blib weirdness ( incidentally this directory is only created when actually install your app ), no duplication of my source tree, no convoluted patters I can think of... unless of course you prefer to just drop everything in some very large directory without any organization. Frank Wiles <frank@wiles.org> http://www.wiles.org http://www.revsys.com	[reply]