Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

You don't write the META.json and META.yml yourself. They're generated. The easiest way I've found to generate them is to run make disttest and then copy them up one directory level from the test-distribution directory to the top level distribution directory. This has always felt wonky to me, and I'm sure I'm missing the most obvious approach. But it works.

These are generated based on what you have in the hash passed to WriteMakefile() in your ./Makefile.PL script. That's where you do your editing. For an understanding on what can go in the WriteMakefile hash, you can read the following documentation:

As you read through that last one, keep in mind the following two points: First, you put things in your WriteMakefile hash to get them into your META.* files. Second, things listed as DEPRECATED FIELDS are often still widely used, and better supported than newer alternatives (I'm thinking of build_requires, configure_requires, recommends, and requires. That doesn't mean you shouldn't use the newer alternatives, but if you do use them, you may need to do ExtUtils::MakeMaker version detection in your Makefile.PL to verify what features are available on a given system.

I've seen the ExtUtils::MakeMaker version checking dance done in a bunch of modules in recent years. It's fine, but it means you need to investigate the Changes file for EU::MM, which is a bit of a pain, or list a modern version of ExtUtils::MakeMaker in a CONFIGURE_REQUIRES section (but only if you detect an older version of EU::MM) or in the prereqs => {configure => {requires => {...}}} section, if a new enough version of EU::MM is detected on the user's system (in which case it may not be necessary anyway, but for consistency is probably worthwhile). The down-side to putting a minimum version requirement on ExtUtils::MakeMaker is that you force yet another dependency on people installing your module in environments where dependency management is difficult, and do so only so that your distribution can have better set-up tooling, not so that the runtime is any better.

Think of PREQ_PM and prereqs => {runtime => {requires => {...}}} as how you indicate what dependencies are needed for your module to run. BUILD_REQUIRES and prereqs => {build => {requires => {...}}} as what is needed to build the module so that it can be installed. Under older versions of BUILD_REQUIRES I think this is also where you list test dependencies. Under newer versions of EU::MM you use the prereqs => {test => {requires => {...}}} namespace to indicate test dependencies. And finally, to set up the dependencies that Makefile.PL needs to produce a correct Makefile, you use the CONFIGURE_REQUIRES or prereqs => {configure => {requires => {...}}}. You can additionally specify prereqs => {develop => {requires => {...}}}, and that can be useful if you have dependencies on development tooling. I don't see that as often. Anyway, this is all documented in the links provided above.

Think of your WriteMakefile hash as the input to ExtUtils::MakeMaker, with the desired output being twofold: One, a Makefile that provides the targets make needs. Two, a make target that can generate the META.* files that CPAN installer and indexing tooling need to catalog the distribution, and to be able to pull it down, as well as its dependencies.


In reply to Re^5: What do I use to release a module to CPAN for the first time? by davido
in thread What do I use to release a module to CPAN for the first time? by Lady_Aleena

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (2)
As of 2024-06-14 02:16 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.