Open ehuelsmann opened 11 months ago
I have no plans to support that feature at the moment.
Thanks for the quick response! Could you provide some more insight into your reasons? It'd help me understand if I should revisit my opinion of the feature myself.
Currently, cpm accurately grasps the dependent modules from MYMETA.json. Scanning pods to detect dependent modules inevitably leaves some ambiguity, which can destabilize the operation of cpm. I do not wish to incorporate such unstable features into the main body of cpm.
If you wish to do so, you can scan the pod yourself and detect the dependent modules:
curl -sL 'https://metacpan.org/dist/DBI/source/lib/Bundle/DBI.pm?raw=1' | perl -nle 'if (/^=head\d\s+CONTENTS/) { $in_contents = 1 } elsif (/^=/) { $in_contents = 0 } elsif ($in_contents) { /^(\S+)/ and print $1 }' | cpm install -
Hmm. I'm not sure why you would call this "unstable": it's been part of CPAN since the oldest CPAN release I could find on MetaCPAN (CPAN-1.58 released on 2000-10-18). The definition (which can be found here) is pretty strict:
The module collection is listed in a POD block which starts with:
=head1 CONTENTS
Followed by a list of modules and their versions:
MODULENAME 1.0.0
Lines starting with a hash (#) character are skipped. So are empty lines. The first line starting with an =
sign (i.e. one that looks like a POD command) terminates the dependency list. The only file scanned for these definitions in a distribution, is the main distribution module.
It's a proven concept since over 23 years. It's always had this definition. Looking at it from that angle, I'd say it's just as stable as MYMETA.yml or MYMETA.json (or even better: META.yml or META.json). I'm afraid I do not see the fragility.
Sure I could do this myself. But the point of having it in cpm
is that others need it when installing the dependencies of my FOSS software releases (http://ledgersmb.org/) or any other case of wanting to install any of the 270 Bundle::* dists released to CPAN.
From the documentation, it seems
cpm
will install only the bundle module, not the bundle contents as specified by the main module's CONTENTS section. (See e.g. Bundle::DBI.)cpan
supports installation of bundles with the simplecpan install Bundle::MODULENAME
.cpanm
supports installation of bundles if you specify the additional--scandeps
argument.Due to the fact that
cpan
supports installation of Bundle::* as part of its regular installation instruction, it feels weird thatcpanm
needs an additional switch to install the Bundle specified deps. To me, it'd make most sense if the installation of specified "Bundle"s would simply be included in the dependency installation.