configure prereqs should be checked at build time about dist-zilla HOT 13 CLOSED

I was in favor of this as a core functionality. But I also wonder about the runtime cost. Develop dependencies are usually met and we just want to fight the case where the developer did not run dzil listdeps --develop --missing | cpanm before running dzil build. Usually the developer that did not run this just after a git pull/svn update will discover the issue when the test build fails.
So I wonder about a functionnality that is useful in a few edge cases, but that has a performance impact on all builds. That's why I've not reported it earlier.

In fact, I introduced injection of develop dependencies in plugins such as [PodSyntaxtTests] and [PodCoverageTests] just as a first step before changing the test code to remove the conditional loading (the eval "use ...") in those tests. The aim is to make author/release testing fail if the develop dependency is missing instead of the test being skipped. Unfortunately I have yet to submit patches for that second step.
So I think that doing it that way both provides a workaournd for the runtime cost issue, and avoid tests being skipped just because the develop dependency is not installed.

Do you have some ideas about some develop dependencies that may be outside of those use cases (either used by dzil plugins or during testing)?

from dist-zilla.

I introduced injection of develop dependencies in plugins such as [PodSyntaxtTests] and [PodCoverageTests] just as a first step

And this is awesome. Every plugin that adds files to the dist should be ensuring that the right prereqs are also injected.

Also, I'd like to change [AutoPrereqs] so that it scans the xt/ directory for develop prereqs, too (we need a new :ExtraTests file finder, and then a few lines of modifications to the plugin itself).

changing the test code to remove the conditional loading (the eval "use ...") in those tests

You can either just use the module directly, or use Test:Requires ... -- which has recently been updated to fail if the module is missing and RELEASE_TESTING is set.

Do you have some ideas about some develop dependencies that may be outside of those use cases (either used by dzil plugins or during testing)?

One situation I've encountered myself is when dist.ini uses a locally-defined plugin (in inc/) -- 1. [AutoPrereqs] doesn't look there (I think it should) to add develop prereqs, but even if the author added them manually, there's nothing that will guarantee they get installed before someone runs dzil build.

from dist-zilla.

On Wed, Jul 17, 2013 at 08:03:55AM -0700, Karen Etheridge wrote:

Do you have some ideas about some develop dependencies that may be
outside of those use cases (either used by dzil plugins or during
testing)?

One situation I've encountered myself is when dist.ini uses a
locally-defined plugin (in inc/) -- 1. [AutoPrereqs] doesn't look
there (I think it should) to add develop prereqs, but even if the
author added them manually, there's nothing that will guarantee they
get installed before someone runs dzil build.

This won't actually do anything useful, because dzil build will be
incapable of running at all if the dependencies for all of the plugins
in dist.ini aren't satisfied. If the plugin in inc doesn't have its
dependencies satisfied, then dzil listdeps will error out (so you
won't be able to see what the dependencies are), and if the plugin does
have its dependencies satisfied, then there's no reason for them to be
listed.

A plugin that ensures that the dependencies for inc plugins are listed
in ; authordep lines may be useful though.

-doy

from dist-zilla.

This won't actually do anything useful, because dzil build will be incapable of running at all if the dependencies for all of the plugins in dist.ini aren't satisfied.

I think you mean -- dzil build will load all plugins, so if the plugin can't load, it doesn't matter if develop prereqs are checked, because we've already died. That's true, but only if compilation of the plugin is sufficient to determine the lack of the prereq. Lots of plugins don't load all their requirements at compile time (because of the needless cost if all we're doing is scanning dist.ini for some reason, and not actually running each plugin) and instead load their dependencies at runtime via 'require' or similar. So it's still important to explicitly declare the necessary prereqs for the plugin, and also check that they're present (I suppose we could wait as long as runtime for the 'require' statement to fail, but avoiding long nasty stack traces is one of the purposes of checking prereqs up front IMHO.)

A plugin that ensures that the dependencies for inc plugins are listed in ; authordep lines may be useful though.

It would be really nice if there was some way of injecting such prereqs into dist.ini in such a way that they were detected first, before Config::MVP::* actually tried to load every plugin. I have no idea where to begin to look to hook in such functionality though -- rjbs, ideas?

from dist-zilla.

I also created https://rt.cpan.org/Ticket/Display.html?id=87024, which I intend to implement when I find the tuits.

from dist-zilla.

BTW I've now patched Module::Build::Tiny to check for prereqs as per the spec at perl Build.PL, ./Build, ./Build test, ./Build install time at Perl-Toolchain-Gang/module-build-tiny#5

IMO it makes sense for Dist::Zilla to assume the installer (EUMM/MB/MBT) actually checks for prereqs properly, so the only thing dzil should do itself is check for 'develop' prereqs... I'll submit a patch for that shortly.

from dist-zilla.

IMO it makes sense for Dist::Zilla to assume the installer (EUMM/MB/MBT) actually checks for prereqs properly,

I disagree, I think the consensus for the recent toolchain development is that the installers should not actually check for prereqs, it should just declare prereqs by dumping them to MYMETA, and actually checking for them should be handled by CPAN clients (cpan[pm]), at least on the end users installation time.

As for the authoring side, it makes sense to ensure that in dzil (before running dzil build), as you originally propose in this issue. I support that idea.

from dist-zilla.

As for the authoring side, it makes sense to ensure that in dzil (before running dzil build), as you originally propose in this issue. I support that idea.

If the checking is not going to happen in EUMM/MB/MBT itself (which sounds like is not going to happen), then it falls to the callers of the build tool (e.g. cpan clients, dzil etc) to then take on that responsibility. If we're in agreement that that's the right place, then I'll pull that code from MBT back into dzil.

(@rjbs: please speak up now if you disagree!) :)

from dist-zilla.

@karenetheridge I think this is the right thing to do because I already had the issue of a dependency not met and the build continuing after a configure step that raised missing dependencies.

For configure/build/test/runtime deps this must be implemented as in CPAN clients by checking MYMETA, not by checking dependencies reported by plugins.
@miyagawa I'm not sure about develop dependencies. Are they propagated to MYMETA ? I'm also not sure if 'develop' dependencies are written by dzil in the Makefile.PL/Build.PL.

from dist-zilla.

@karenetheridge
For dzil build only develop prereqs should be checked, using plugin info. This shoud be implemented in Dist::Zilla::Dist::Builder::build_in.
For dzil test all dependencies should be checked:

• develop prereqs will be enforced because Dist::Zilla::Dist::Builder::test calls Dist::Zilla::Dist::Builder::build_in.
• configure prereqs must be checked from the META.{json,yml} in the build dir
• build/runtime/test should be checked from the MYMETA after the configure phase.

Unfortunately the Dist::Zilla::Role::BuildRunner doesn't have configure separate from build. This is the first thing that we should fix. Cc: @Leont

from dist-zilla.

@dolmen

I'm not sure about develop dependencies. Are they propagated to MYMETA ? I'm also not sure if 'develop' dependencies are written by dzil in the Makefile.PL/Build.PL.

Yes, if you use Plugin::PrereqsFromCPANfile, you can declare develop dependencies into META.json. You're right that they are not output into Makefile.PL or Build.PL, since they're not directly supported by MakeMaker/MB. However, if they exist in META.json, they are preserved when dumping MYMETA files, at least by MBT and newer version of MakeMaker.

from dist-zilla.

Yeah, configure/build/runtime/test can easily be tested for on the correct moments. dzil should probably act as a partial CPAN client there and warn for missing dependencies.

from dist-zilla.

[Test::ReportPrereqs] and [Test:CheckDeps] both have this verification ability; the related tickets have since been closed.

from dist-zilla.