Re: DWIM inc bundling design discussion (LONG)

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