Polyglot has asked for the wisdom of the Perl Monks concerning the following question:

Silly question, perhaps, but I'm quite a beginner with making a CPAN-worthy module (yes, still working on that, between other real-life projects that hinder progress)--and searching online did not help me find an answer:

According to the h2xs utility, the README file should contain a list of the module's dependencies. I have a hard time thinking such things as use strict; should need to be listed, but what about require Exporter;?

If my dependencies are strictly limited to the following, which of these, if any, should be listed in the README file? 

use 5.008003;
use strict;
use warnings;

require Exporter;

[download]

I would think these are all virtually taken for granted, and ubiquitous on ordinary installations of Perl. Do I still list them? If not, do I report "No dependencies"? (That doesn't seem quite accurate, either.) What is considered the best practice here?

Blessings,

~Polyglot~

Replies are listed 'Best First'.
Re: Listing dependencies for Perl modules--should even the common ones get listed?
by 1nickt (Canon) on Nov 26, 2023 at 12:26 UTC
[reply]
Re: Listing dependencies for Perl modules--should even the common ones get listed?
by hippo (Archbishop) on Nov 26, 2023 at 13:48 UTC

    Definitely specify the minimum required version of Perl and your use of any modules such as Exporter. Just because they are in core today doesn't mean that they always will be.

    You can include the pragmata or not as you wish. I doubt anyone is going to have a strong opinion on those either way.

    🦛

[reply]

      That also goes for any sub-dependencies that YOUR dependencies consider optional. One of the classics is (or rather: "was", thankfully) IO::Socket::INET6 when you are using IO::Socket::IP to connect over the network. When your software requires IPv6 support, you will have to make sure that the required modules actually get installed. Believe me, more than once my servers were IPv6-blind because i forgot...

      PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
[reply]
Re: Listing dependencies for Perl modules--should even the common ones get listed?
by kcott (Archbishop) on Nov 27, 2023 at 19:11 UTC

    G'day Polyglot,

    My thinking on this has varied over time: no core modules; no core pragmata; all modules.

    My current thinking is:

    • I state: "Requires a minimum of Perl vX.Y.Z and uses various modules available in that version."
    • I list all CPAN modules (regardless of whether they're common or not).
    • I list all 3rd-party modules and libraries.
    • Modules that are required for Author only tests (e.g. Test::Pod) are listed separately in README(.md) but are excluded from Makefile.PL.

    I concur with what ++hippo pointed out: "Just because they are in core today ...". For example: 

    $ corelist CGI

Data for 2023-09-20
CGI was first released with perl 5.004, deprecated (will be CPAN-only)
+ in v5.19.7 and removed from v5.21.0

    [download]

    And, of course, my thinking on this may change yet again at some future time. So, consider this as only suggestions and guidelines; then make your own choices.

    — Ken

[reply]
[d/l]
[select]
      I list author-only stuff under `develop.requires`. A snippet from GraphQL's Makefile.PL: 
      WriteMakefile(
  NAME             => 'GraphQL',
# ...
  META_MERGE => {
    "meta-spec" => { version => 2 },
    dynamic_config => 0,
    resources => {
      x_IRC => 'irc://irc.perl.org/#graphql-perl',
      repository => {
        type => 'git',
        url => 'git@github.com:graphql-perl/graphql-perl.git',
        web => 'https://github.com/graphql-perl/graphql-perl',
      },
      bugtracker  => {
        web => 'https://github.com/graphql-perl/graphql-perl/issues',
      },
      license => [ 'http://dev.perl.org/licenses/' ],
    },
    prereqs => {
      develop => {
        requires => {
          'Test::Pod::Coverage' => '1.08',
          'Test::Pod' => '1.22',
          'Pod::Markdown' => 0,
        },
      },
      runtime => {
        suggests => {
          'Cpanel::JSON::XS' => '3.0237',
          'JSON::XS' => 0,
        },
      },
    },
  },
);

      [download]
      That lets me minimise or avoid specifying them separately in continuous integration (CI) config.
[reply]
[d/l]

        G'day etj,

        That's a far more complicated Makefile.PL than I currently write; however, I can see some distinct benefits to using it.

        I found ExtUtils::MakeMaker - META_MERGE which has some limited information. It doesn't mention {prereqs}{develop}{requires} or {prereqs}{runtime}{suggests}; I suspect there may be others.

        Can you point me to a definitive reference for the META_MERGE key? Thankyou.

        — Ken

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom