Re: thoughts on DWIM bundling

> What do people think?

I think both (1) and (2) are going to suffer from architecture
dependency problems, amplified by recursion.

I also think that blindly using a newer version of something without
knowing if it's compatible with the bundled one is asking for trouble.
But that's more a call to make sure a compatibility assurance
mechanism is implemented, rather than saying don't do it.

Adam K

2009/9/9 David Golden <[email protected]>:
> Having looked at latest.pm (c.f. inc/latest.pm in the M::B source) I
> have to say that I like it.  How about 'newest.pm' as an alternate
> name?  (Apologies to rgs and ex::newest)
>
> Getting the dwimmery to work is a bigger issue.  There's a
> quick-and-dirty way and there's a correct way.  (And probably options
> in between.)
>
> (1) Quick and dirty -- for whatever needs to be bundled, recursively
> copy everything from the current perl library path into the right
> directory in inc/ (e.g. Module/Build.pm and Module/Build/* into
> inc/inc_Module-Build)
>
> (2) Correct -- for each configure_requires, use CPAN(PLUS) (as defined
> by the cpan_client property) to download the appropriate distribution
> from CPAN and install into inc/ directories.  All 'requires'
> dependencies of the configure_requires must be processed similarly.
> If a minimum perl prerequisite is defined, any of these modules
> satisfied by core modules in the minimum perl can be skipped.  (And
> anything that installs an arch-specific component is a fatal error.)
>
> I'm tempted to do #1 just to prove the concept and get going, but it's
> fragile and won't generalize, so I don't think it's a long term
> solution.
>
> I thought about using packlists, but that only works for modules
> installed from CPAN -- falling back to using the core packlist winds
> up being just a variation of #1 above.
>
> What do people think?
>
> -- David
>