Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Firstly, thanks for pointing out there is a discussion about something that is potentially of interest to the WHOLE of CPAN and not just a small subset. Wouldn't it be better to have a specialist list regarding META.yml specs, that discusses these sort of changes? A Module::Build list is not something I am going to sign up as I tear my hair out with MB at the best of times.

    When I first saw your post, I assumed this was part of the Module Authors list discussion a few weeks ago, but struggled to find the th

    • However, I do think requires_perl is not appropriate, requires_executable using the same format as the requires would be more useful.

      I came to that conclusion, too, but from a desire not to have a whole salad of "requires_perl", "recommends_perl", "test_requires_perl", "configure_requires_perl", etc...

      The trouble is a general purpose executable/external utility specification is a whole lot more difficult. Previously, everything in the META.yml was about the module being shipped. Now we want to specify things that aren't under Perl's control. And then things rapidly get meta. What if I just need a mail server? You don't want to hard code an executable, you want to say "mail server". Debian has this in the form of its "provides" key and the idea of virtual packages [debian.org]. But Debian controls the operating system, we don't.

      So, pragmatically, requires_perl is a simple solution to an existing problem that we can implement now whereas requires_external or a big mess.