On Sep 10, 2009, at 12:57 PM, David Golden wrote:
(1a) Should bundling modules into inc/ happen in $source or $distdir?
$distdir. The same should be true of MANIFEST, META.yml, and other
generated files, AFAIC.
(1b) For either choice in #1a, how should the behavior of “bundle_inc”
change depending on whether $source/inc exists or is missing?
Not at the first cut of the feature. Perhaps later $source/inc could
be copied to $distdir/inc and updated as appropriate for a distribution.
(2a) Should inc::latest work for any module at any depth in a
directory bundled in inc/? (E.g., use inc::latest
‘File::Spec::Functions’) Or should inc::latest only be allowed for a
“top-level” module? (e.g. use inc::latest ‘File::Spec’)
Any level, just like `use`. People often don't realize that they're
not requiring a top-level module (better name: primary distribution
module, since there may be other modules in a distribution that are in
different packages).
(2b) Should modules to bundle be based on configure_requires or
modules actually loaded by inc::latest or by some other specification?
How does this depend on the answer to #2a?
<snip />
If inc::latest works for a module of any depth, then the requested
module does not necessarily directly map to a distribution, and thus
it’s more difficult to determine the set of modules that should be
bundled from the list loaded by inc::latest. In this case,
configure_requires could be used to indicate the ‘distribution’
equivalents to bundle, even if inc::latest loads a deeper module.
E.g. configure_requires could have File::Spec even though inc::latest
is loading File::Spec::Functions. (This becomes relevent for M::B if
someone want to use inc::latest ‘Module::Build::Functions’ instead of
Module::Build)
I think that this would be confusing. I should be able to say
`inc::latest File::Spec::Functions` and Module::Build can find the
distribution and bundle it. I may not even know what the distribution
module name is -- or care.
(3) How should we map from a module name to bundle to a set of
module files?
Whether derived from configure_requires or inc::latest loaded modules,
we have a list of module names but need a set of related module files
that must be copied to the right place in inc/.
The purest solution would use a CPAN index to identify the
distribution that provides the given module name. Then that
distribution could be bundled in a variety of ways.
+1
A pragmatic solution would be to recursively copy all files under the
top-level module name.
You'll miss stuff that way. And don't forget dependencies!
This would be the reason to support a $source/inc that gets copied to
$distdir/inc and updated there. So If I have $source/inc/inc_File-Spec-
Function that just has the one module, then my inc::latest
File::Spec::Function calls would find it there and not bother to try
to download or install anything else.
(4) Should inc::latest emulate “require” or “use”? If “use”, should
it be able to handle the full semantics of “use MODULE VERSION LIST”
and how?
Right now, inc::latest require()’s the module and calls import() with
zero or more arguments. It does not support *not* calling import and
does not support VERSION checking. Are these important? Not getting
default imports() could be important. Should that just be an explicit
undef? “use inc::latest ‘Foo::Bar’ => undef”
You should be able to tell it not to call `import`. The version number
shouldn't be important, since I bundled it!
That's all from me for now. For anyone who read this far, thank you.
Your thoughts and reactions are greatly appreciated.
HTH,
David
