2

I have a requirement to develop a group of Perl modules for in-house work. I would like all of them to be formed in to one family or suite of modules, rather than being separate.

For example, the suite would be something like:

MySuite::App::Module1
            ::Module2
MySuite::Env
MySuite::Utils::Logger
              ::Util2

I've gone through perlmodstyle, perlnewmod etc, but they all seem to focus on tips for developing individual modules. What are the tips/best-practices when it comes to developing/distributing a suite such as this? (the individual modules in the suite could be written by different developers)

Ishan De Silva
  • 935
  • 2
  • 8
  • 22

2 Answers2

2

It's not much different than single-module distributions. Two additional established conventions are:

  1. Place modules hierarchically in the lib directory.

    MySuite::App::Module1       →   lib/MySuite/App/Module1.pm
MySuite::App::Module2       →   lib/MySuite/App/Module2.pm
MySuite::Env                →   lib/MySuite/Env.pm
MySuite::Utils::Logger      →   lib/MySuite/Utils/Logger.pm
MySuite::Utils::Util2       →   lib/MySuite/Utils/Utils2.pm

  2. Pick a main module that becomes the distribution name. Your example looks like it should have an additional lib/MySuite.pm with package statement MySuite and not much code and some entry point documentation. Assign this module as module_name in the Build.PL file.

For more info on packaging in general, see:

Feedback/critique on your progress is available from:

Community
  • 1
  • 1
daxim
  • 39,270
  • 4
  • 65
  • 132
  • Thanks for the answer. Appreciate if you can clarify the following a bit more. (a) When I use Module::Starter, it generates a Makefile.PL and not Build.PL. Are they the same? (b) Module::Starter puts each module under a separate root directory if they are created at different times. What should be done to move them to the original suite's root dir? (c) Any idea of how tests should be written when modules are combined as in (b)? Thanks for your time. – Ishan De Silva Mar 15 '12 at 11:46
  • ⒜ Makefile.PL and Build.PL are not the same (different API), but serve the same purpose. ⒝ Move the subdirectories `lib`, `t`, `script` into the suite base directory. Merge the Build file/README/distro metafiles into the equivalent files in the suite base directory. ⒞ Since testing by default run all `t/*.t` files, no work is necessary other than moving the test files as I just wrote. – daxim Mar 15 '12 at 18:38
1

Use the h2xs command line tool shipped with perl. It will create a very useful perl module skeleton (that is particular suited for distribution at CPAN). Type in your shell:

$ h2xs -X MySuite

This will create a single distribution with that particular module skeleton placed into lib. Study it and create the other .pm files as needed below lib. Study the "package" line in the source and match the file path; you should get the basic idea. For instance:

  $ cd MySuite
  $ touch -p lib/MySuite/App/Module.pm
  $ touch -p lib/MySuite/Env.pm
  $ ...

would be the basic step to add more modules to your distribution. Any time you will add another .pm file or change filenames, issue an

  $ perl Makefile.PL  (only first time or "Makefile" not present)
  $ make manifest

to sync your MANIFEST file; it will add all files within the module distribution. This allows you to use 

  $ make dist

to create an MySuite-0.1.tar.gz archive for you. Finally, you can test your suite with:

  $ make test

Together, h2xs is very handy for module authors and takes the burden of preparing the basic module distribution infrastructure. It creates placeholders to fill in specific documentation and creates a Makefile to manage your distribution - as it grows bigger, you'll appreciate it. Send your module to CPAN, and you will be pleased how well it will be indexed.

muenalan
  • 588
  • 4
  • 8