Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Bundle::* modules/dists #241

Open
ehuelsmann opened this issue Oct 21, 2023 · 4 comments
Open

Support for Bundle::* modules/dists #241

ehuelsmann opened this issue Oct 21, 2023 · 4 comments

Comments

@ehuelsmann
Copy link

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 simple cpan 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 that cpanm 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.

@skaji
Copy link
Owner

skaji commented Oct 21, 2023

I have no plans to support that feature at the moment.

@ehuelsmann
Copy link
Author

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.

@skaji
Copy link
Owner

skaji commented Oct 21, 2023

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 -

@ehuelsmann
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants