Qiang has asked for the wisdom of the Perl Monks concerning the following question:

mostly what we develop is online applicaiton under solaris 8 or 10, Perl 5.8.7.

we are in process of introducing standards to our Perl development ( Perl is still relative new in this place ) . currently, the unix group supplies us a separate Perl under /usr/local/ and install every requested module for us into that tree. their support has been lacking due to the our usage of Perl going up. We often have to wait for weeks to have something installed.

thus, I am trying to find better way to manage modules by ourself. we have modules from CPAN, modules written by me and others.

been searching around, I have found some ideas from the following nodes.

  • Management of perl modules in enterprise?
  • Professional development with Perl - how it's done?
  • Maintaining an Enterprise Perl Distribution

    to summary a bit:

    1. have a centralized place to hold all modules. use rsync or cvs to keep the modules up-to-date among servers.

    2. build apps with all their libraries local. keep track of which app use what version of the module. update module case-by-case. such as krang

    I am leaning toward the option 1. because having modules in one place seem to cleaner and easy to manage. my guess is that there won't be many module upgrades. if there is a major bug fix or a necessary feature for a module, we test it out on Dev, QA then roll it out to production.

    in the end, if we have perl modules under /team/perl_lib/, we can just include that path in the "use lib '/team/perl_lib'; ".

    that's fine for pure perl module. but i am uncertain how to deal with the XS module that required to compile. I am thinking about building XS modules in a desinated location and then copy it to the central Perl library dir. however, try building Text::CSV_XS today, the binary is stored under /build_dir/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/Text/. the Perl module is installed under /build_dir/lib/perl5/site_perl/5.8.7/sun4-solaris/Text/. how do i mix it with the pure Perl modules and still be able to use 'use lib '/team/perl_lib' ?

    i am also interested in your take on module managment.. which method do you prefer and why?

    • Replies are listed 'Best First'.
    Re: module management in enterprise?
    by samtregar (Abbot) on Apr 04, 2007 at 21:18 UTC
      my guess is that there won't be many module upgrades.

      I would guess your guess is wrong. Consider what will happen if a legacy application requires one version of a module and a new application needs a new version. This is more common than you might think - some CPAN authors aren't as careful about backwards compatibility as others!

      Of course, I imagine it comes as no surprise that I prefer the Krang method. It's worked great for us and I definitely plan to use it on any projects I get involved with in the future. I suppose it's a matter of personal taste, but I find packaging an application as a self-contained entity is quite clean. External dependencies and complex setup procedures seem ugly to me...

      -sam

    		[reply]
        Consider what will happen if a legacy application requires
 one version of a module and a new application needs a new
version. This is more common than you might think - some 
CPAN authors aren't as careful about backwards compatibility as others!
        in that case, what about i do: update the module from the central location. and in the legacy app, install the older module in local lib ($Project_Root/lib) and add a use lib '$Project_Root/lib' to make sure it continue use the older module.

        back to the krang way, I have looked at Krang many times recently and learned a lot about building large Perl app. Krang includes src of all modules and the krang_build makes it easy to build krang from scratch. the Krang::Platform looks easy enough to adopt to our environment.

        but I don't feel like building every modules out of src for every release or rebuilding a module for different app. instead, I would like to compile the module once, all the prerequsite modules and reuse them in other apps (copy the modules to the app's local lib) when approriate.

    		[reply]
    [d/l]
    [select]
          Sounds like you're going to do both then - have global shared modules and local copies as necessary. To me that seems ugly and likely to be error-prone. You'll probably find out you need a local copy only after things break - after the module you want to copy is overwritten! Not an insurmountable problem by any means, but something I don't ever have to worry about...

          -sam

    		[reply]
    Re: module management in enterprise?
    by derby (Abbot) on Apr 04, 2007 at 21:25 UTC

      in the end, if we have perl modules under /team/perl_lib/, we can just include that path in the "use lib '/team/perl_lib'; ".

      If you have control over the perl install, you can rebuild perl and add '/team/perl' to @INC at build time, then your scripts do not need to anything special.

      -derby
    		[reply]
    Re: module management in enterprise?
    by Joost (Canon) on Apr 04, 2007 at 21:02 UTC
    [reply]
    [d/l]
    [select]
    Re: module management in enterprise?
    by lostsoul (Sexton) on Apr 05, 2007 at 12:45 UTC
      you can set this in your .bashrc to avoid having to "use lib" all the time: 
      export PERL5LIB=/team/perl_lib:/team/cpan

      [download]
    		[reply]
    [d/l]

    Back to Seekers of Perl Wisdom