Distros built with Minilla do not declare the same deps in their cpanfile and META.json files

[autarch]

This is really confusing if you're trying to build tooling to operate on distros. I think it's reasonable to assume that a distro with both a cpanfile and META.json will have the same deps in each, so that as a tooling author I can just pick the first one I find and use that. I'd prefer to use the cpanfile because for my purposes I just want to produce a cpanfile, and if one already exists I can copy it.

I made a new minilla-built with minil new Testing. Then I ran minil dist in the newly created directory and untarred the resulting tarball.

The cpanfile:

requires 'perl', '5.008001';

on 'test' => sub {
    requires 'Test::More', '0.98';
};

The META.json:

   "prereqs" : {
      "configure" : {
         "requires" : {
            "Module::Build::Tiny" : "0.035"
         }
      },
      "develop" : {
         "requires" : {
            "Test::CPAN::Meta" : "0",
            "Test::MinimumVersion::Fast" : "0.04",
            "Test::PAUSE::Permissions" : "0.07",
            "Test::Pod" : "1.41",
            "Test::Spellunker" : "v0.2.7"
         }
      },
      "runtime" : {
         "requires" : {
            "perl" : "5.008001"
         }
      },
      "test" : {
         "requires" : {
            "Test::More" : "0.98"
         }
      }
   },

What's particularly problematic in my case is the missing configure phase requirements in the cpanfile, but I really think this should just match up 100%.

[skaji]

I think this is intentional.

[autarch]

@skaji Could you explain why? This is quite confusing to me, and I can't see what purpose it would serve for anyone using these distros. The cpanfile is just missing data and cannot be used for its intended purpose.

[autarch]

I would note that simply not providing a cpanfile would be fine.

[skaji]

Could you explain why?

cpanfile is for development. META.json is for installation. So Minilla treats them individually. I see your point. But, it's just how Minilla works.

What's particularly problematic in my case is the missing configure phase requirements in the cpanfile

As for Module::Build::Tiny, we rarely need it in development phase. Just run prove -l t.

[miyagawa]

I think it's reasonable to assume that a distro with both a cpanfile and META.json will have the same deps in each, so that as a tooling author I can just pick the first one I find and use that.

I think that's a wishful thinking on your part, @autarch :)

I understand that there are two kinds of cpanfile usages out there in the wild, as shown by the two dzil plugins:

• https://metacpan.org/pod/Dist::Zilla::Plugin::CPANFile (emit META.json to cpanfile)
• https://metacpan.org/pod/Dist::Zilla::Plugin::Prereqs::FromCPANfile (read cpanfile to emit META.json)

i think you're suggesting the former, and while my personal preference is the latter (i.e. merge what is required to build the modules with what's in cpanfile, then dump to META), the reality is that either way is fine, and the tools should not read cpanfile to figure out the dependencies, except the tools made specifically to read the file for non-CPAN module dependencies, such as Carton or Carmel. For normal CPAN modules/Linux distros, META.json is the source of truth for what is required to build the whole thing.

[autarch]

@miyagawa - Ok, thanks for the clarification.

But if this is the case, I don't see what purpose the cpanfile could possibly serve for CPAN modules, either in the case where the file is checked in or when it's shipped with the tarball on uploading to CPAN.

You're basically saying that in either case we cannot rely on it having any of the prereqs needed for any particular use case. So I would still say that if you're not going to make sure it's accurate, it would be better to not include it at all.

[autarch]

@miyagawa - or maybe you're saying that the expectation is that Minilla users will keep their cpanfile up to date manually?

[miyagawa]

that Minilla users will keep their cpanfile up to date manually?

Yeah, I can't speak for all Minilla users, but for me, this is how i maintain the dependencies using Dist::Milla (sharing the same concept with Minilla). I manage dependencies primarily in cpanfile locally, and then the tool will figure out the rest to dump to META.json before shipping to PAUSE.

As for the inclusion or exclusion of cpanfile in the dist, i don't know -- it's not like the size is important here, and this is similar to how Dist::Zilla distributions normally contain dist.ini in their PAUSE package, and i don't see why we have to exclude cpanfile from the tarballs.

[autarch]

As for the inclusion or exclusion of cpanfile in the dist, i don't know -- it's not like the size is important here, and this is similar to how Dist::Zilla distributions normally contain dist.ini in their PAUSE package, and i don't see why we have to exclude cpanfile from the tarballs.

I'm not suggesting it needs to be excluded or included. I'm saying that if it's included it should be correct.

If you look at the first message in this issue you'll see what Minilla produces by default (with no hand editing). Let's assume that the distro someone is working on has no other deps. Is this something developers should be shipping to CPAN? I would say no, since it's missing the configure and develop prereqs.

[miyagawa]

Let's assume that the distro someone is working on has no other deps. Is this something developers should be shipping to CPAN? I would say no, since it's missing the configure and develop prereqs.

The complete dependency list is there in META.json so yes this is absolutely something that can be shipped to CPAN.

While you develop, you're supposed to declare new dependencies in cpanfile, and Minilla will add more stuff so that you can configure the module, and run tests that Minilla automatically generates.

I understand what you mean by "Minilla users should maintain the cpanfile manually" now -- No, that's not what I meant. In this usage of cpanfile, you're going to declare modules that are required by your module, but then the tools (Minilla, or Dist::Milla, which is based on dzil) can add things on top, based on the additional stuff added by the configuration, and that information is dumped to META.json at the end.

At the end of the day, cpanfile is not supposed to be the source of truth for CPAN module dependencies once it hits PAUSE, and since it's even Turing complete (it is an arbitrary perl code you eval basically) you should avoid relying on it for a CPAN module if you can (i get that we have to run Makefile.PL for modules with a dynamic configuration anyway).

[autarch]

@miyagawa - Okay, thanks for the clarification. I can make the thing I'm working on just start with the meta files. I wanted to use the cpanfile if it was available because ultimately I feed this stuff into cpm to install the modules, so if I can use an existing cpanfile this becomes much simpler.