Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

modular app development - where do your modules live?

by metaperl (Curate)
on Jul 20, 2009 at 12:34 UTC ( #781609=perlmeditation: print w/replies, xml ) Need Help??

I'm developing Perl applications at a company. I have a lot of modules. For the web app, I have Model::* and View::* classes which are manipulated from CGI::Application.

For my command-line apps, I have a series of Perl classes representing targets for the command-line apps.

Now for the issue

Both my web and command-line apps are designed to "bootstrap" themselves from a single environmental variable, which points to the root of the source code repository.

What this means is that my apps are easily relocatable to anywhere - you just check them out of the source repository and set the environmental variable and you are ready to go.

On the other hand...

My boss thinks that all modules should be built with something like Module::Starter and be part of a make, make install cycle.

Which process do you prefer?

Personally, the make, make install is just too slow for a rapid edit, run, edit cycle. It would make me 20% slower with no apparent gain.

Also, adding another module would mean editing a MANIFEST file each time.

I simply dont see the Module::Starter paradigm as practical for development of the plethora of modules in a medium-large Perl app... how about you?

Replies are listed 'Best First'.
Re: modular app development - where do your modules live?
by zby (Vicar) on Jul 20, 2009 at 12:49 UTC
    The benefit of using the standard CPAN way of packaging modules makes it easy to relocate them not only around one system but also between systems where you need to keep track of dependencies. Also I don't usually install the modules when doing development so I don't lose the time for make install (but I do make test and from time to time also make disttest).
Re: modular app development - where do your modules live?
by Corion (Pope) on Jul 20, 2009 at 12:42 UTC

    I think you have it wrong on two counts:

    1. If you can't justify the benefits of your approach towards your boss, turning to us is a bad technique.
    2. Personally, the make, make install is just too slow for a rapid edit, run, edit cycle. It would make me 20% slower with no apparent gain. - why do you think you need to install just for testing? Just run your tests using perl -I lib from your distribution directory and you're all set. Your argument regarding the MANIFEST is a strawman - you can easily write a Perl program to maintain your MANIFEST file.
      I think you have it wrong on two counts:
      and as usual, I disagree with you entirely (grin) But thank you for feeding back, ALL feedback is appreciated.
      If you can't justify the benefits of your approach towards your boss, turning to us is a bad technique.
      I emphasize using Perl as a community language and am turning to you to get perspectives on an interesting subject about Perl software engineering. What exactly is wrong about soliciting the advice of a respected bunch of peers on a subject?

      Your argument regarding the MANIFEST is a strawman - you can easily write a Perl program to maintain your MANIFEST file.
      make manifest does that already, now that I recall.
      why do you think you need to install just for testing? Just run your tests using perl -I lib from your distribution directory and you're all set.
      I dont mean testing the modules, I mean testing the (web/command-line) app which uses the modules.
        I emphasize using Perl as a community language and am turning to you to get perspectives on an interesting subject about Perl software engineering. What exactly is wrong about soliciting the advice of a respected bunch of peers on a subject?

        Trying to use the community to overrule your boss is generally a bad idea. ;)

        It's not that you are turning to the community to help. It's that your boss has already said what they think is the correct solution, and you want to refute that with a buch of comments from a website. Not a good plan.

        I don't mean testing the modules, I mean testing the (web/command-line) app which uses the modules.

        If you write good module tests, that should be a very short process.

Re: modular app development - where do your modules live?
by ctilmes (Vicar) on Jul 20, 2009 at 13:01 UTC
    I'm going to have to agree with your boss.

    Personally, the make, make install is just too slow for a rapid edit, run, edit cycle. It would make me 20% slower with no apparent gain.

    There are a couple cycles you are looking at, the "developing individual CI module: edit->unit test->edit->unit test->..." cycle where, as pointed out above, you don't really have to "make, make install" every time.

    The other is the "install multiple CI modules->integration test->find bug" where you are really testing the install process itself, so it really makes sense to do a full "make install".

    If your whole app fits into one CI (configuration item), where no module is (or ever will be) useful without all the others (take a close look if this really is the case), then the vast majority of your development time can be spent between "make" and "make test", only rarely getting to "make install".

Re: modular app development - where do your modules live?
by Bloodnok (Vicar) on Jul 20, 2009 at 14:30 UTC
    Hmmm, I'm obviously also not alone in being with your boss on this one.

    I've never used Module::Starter - plain, good old h2xs has always fitted the bill perfectly well for me. With this make & make test are both dependencies of make install, so once the makefile has been generated, there's only ever one command to recall and re-run - and unless it's been Windoze-based perl/make session to a networked filesystem, any extra time spent is negligible ... to the point of being infinitesimally small.

    The one thing I notice you haven't mentioned is the notion of unit test - the skeleton for which comes for free with h2xs (and possibly/probably Module::Starter) - and (as mentioned above) gets executed prior to installation - thus providing a far greater degree of confidence in the installed module (assuming adequate test script(s) coverage).

    WRT ...adding another module would mean editing a MANIFEST file each time., you self-evidently haven't heard of make manifest (having first tidied up the development area).

    A user level that continues to overstate my experience :-))
      Though its a little young, i like the stubs/layout Module::New generates
Re: modular app development - where do your modules live?
by DStaal (Chaplain) on Jul 20, 2009 at 13:30 UTC

    Using the appropriate tools and design, you'll never have to edit a MANIFEST, and you only have to do a make test for most of the development cycle, I find. (Or a prove -b) Most of the module tools can build a MANIFEST for you these days, and you aren't designing your modules to be so closely coupled that a change in one means a change in the other, right?

    Personally, I dislike 'unseen configuration', which I feel environment variables are. And using module tools means it's easier to then use packaging tools, and install tools, and uninstall tools. Oh, and CPAN as well: The modules tools will usually let you just bundle and go.

    (One other thing: None of my production boxes have access to my CVS repository. Which would make the 'just check them out' part hard.)

Re: modular app development - where do your modules live?
by JavaFan (Canon) on Jul 21, 2009 at 13:14 UTC
    I'd say introducing an intermediate tarball is just a waste of resources. I presume you're working in a team - how does your boss envision working in a team, and each member making tarballs? Do you handmerge?

    At $WORK, we use git (no doubt a dozen or more other source control systems would work as well). Each developer checks out the source, goes to whatever branch (s)he's working in, and uses an environment variable (PERL5LIB!) to point to the sources. Production machines checkout from git as well; then use rsync to sync between machines that play identical roles. CPAN modules are distributed using yum and rpms; the handful of house-written XS modules are distributed using yum and rpms as well, to avoid having to compile C on production machines, which would slow down the deployment process.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://781609]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (None)
    As of 2021-10-19 03:36 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?
      My first memorable Perl project was:







      Results (76 votes). Check out past polls.

      Notices?