I'll take a stab at starting a reply for this...
On Fri, December 10, 2010 4:22 am, David Christensen wrote:
> module-authors:
>
> I have a library of CPAN modules that I've turned into a CPAN bundle:
>
>
> http://search.cpan.org/~dpchrist/Bundle-Dpchrist-1.044/lib/Bundle/Dpchrist.pm
>
> If I'm remembering correctly, each module should contain just one *.pm
> file.
Not necessarily. That's a typical usage though.
If you separate 'module' from 'distribution', then I'd make that a cleaner
yes. One CPAN distro should contain all the modules needed for a basic
use of some functionality, which is often one module, but may be more.
> The top half (Dpchrist::ExtUtils::MakeMaker through Dpchrist::Debug) are
> what I'd call core functionality, while the bottom half are geared
> towards solving specific problems. I've put them all into one CPAN
> bundle to simplify installation.
>
> As I developed the modules, I tried to break down functionality into
> small units, with one CPAN module per unit. I've designed the modules
> and ordered them in the bundle such that each module only depends upon
> the module(s) above it (to avoid circular dependencies).
>
> Dpchrist::ExtUtils::MakeMaker adds Makefile overrides to
> ExtUtils::MakeMaker::WriteMakefile() to simplify my development and
> release processes. All of the modules in the bundle include the
> following in their Makefile.PL:
>
> # Makefile.PL
> eval {
> require Dpchrist::ExtUtils::MakeMaker;
> die 'Skipping Dpchrist::ExtUtils::MakeMaker'
> unless 1.013 <= $Dpchrist::ExtUtils::MakeMaker::VERSION;
> import Dpchrist::ExtUtils::MakeMaker (
> # ...
> );
> };
> warn $@ if $@;
>
>
> The 'die' is there because CPAN tester machines were loading broken
> earlier versions of Dpchrist::ExtUtils::MakeMaker and failing. Is there
> a better way to specify a minimum version while loading a module?
Look at the meta.yml file specs, and the docs for PREREQ_PM in
ExtUtils::MakeMaker. (Which lists the format for all the perquisite
options.) This functionality is built in.
> The Makefile.PL for Dpchrist::ExtUtils::MakeMaker adds the following
> before 'eval':
>
> use lib './lib';
>
> This is the only way I could figure out how to have
> Dpchrist::ExtUtils::MakeMaker load the current version of itself during
> 'perl Makefile.PL'.
>
>
> At one point, the Makefile.PL for Dpchrist::ExtUtils::MakeMaker looked
> like this:
>
> # Makefile.PL
> use lib './lib';
> use Dpchrist::ExtUtils::MakeMaker (
> # ...
> );
>
> It seemed to work, but the first form seems safer at the risk of
> forgetting to update the version number (as I did with 1.020). What is
> the best way for a module that enhances ExtUtils::MakeMaker to load the
> current version of itself during 'perl Makefile.PL'?
>
>
> I've added Dpchrist::ExtUtils::MakeMaker to the PREREQ_PM arguments for
> all the other modules. Strictly speaking, Dpchrist::ExtUtils::MakeMaker
> only affects the generated Makefile targets and rules for each module,
> not the Perl functionality of those modules. I'm pondering whether or
> not I should have these prerequisite entries.
Sounds like they should be in build_requires, not requires.
> Dpchrist::Test is another special case: Dpchrist/Test.pm does nothing
> other than provide $VERSION. Modules that want to use it's t/* scripts
> do so via symbolic links in the CVS repository. Is there a better
> approach to libraries of test scripts?
>
> Dist::Zilla mentions a directory with test scripts just for development,
> not installation. Is this functionality available outside of Dist::Zilla?
>
> I have the desire to use functions from dependent core modules in
> prerequisite core modules. For example, I'd like to use Dpchrist::Is
> functions in Dpchrist::ExtUtils::MakeMaker. But, to do so would create
> circular dependencies. The only idea I have for a solution is to put
> all the interdependent *.pm modules into one CPAN module. Is there
> another way?
Probably, but that sounds like a decent solution. ;)
> If I do put multiple *.pm files into one CPAN module, what is the proper
> way to load the modules from external code and/or from within? While
> studying ExtUtils::MakeMaker code, I saw some comments that led me to
> think that the solution is to 'use' the main module from external code
> and 'require' the subordinate modules from the main module (?).
Depends on what you need to do. You can 'use' or 'require' the
subordinate modules as needed in most cases. Just look up the perldoc on
each to for when to use which. ;) I tend to use 'require's if the module
is optional, and 'use' if it isn't.
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
