Ending Build.PL if there are missing modules

[Alberto Simões]

Hello

Builder->new seems to check if all required modules are available. But
if any fails, it continues to process the Build.PL file.

Is there any way to make it stop?

Thanks

[Leon Timmermans]

2012/2/3 Alberto Simões <al...@alfarrabio.di.uminho.pt>:

Hi Alberto,

You shouldn't make it stop. «perl Build.PL» does configuration, not
building. Hence build or runtime requirements are not required to be
satisfied. What you're observing is not an error in any way, but an
essential step in the process. It gives the install tool the chance to
tell the cpan client (or the end user, if he's installing by hand) the
opportunity what dependencies to install.

If there are any missing dependencies, you'll notice it soon enough
(in particular when doing «./Build test».

Leon

[Adam Kennedy]

While I agree it needs to finish, I do kind of wish dependencies could
be enforced at the build module level so that tests couldn't run until
dependencies are satisfied.

Adam

[Alberto Simões]

Hello

On 04/02/12 01:33, Michael G Schwern wrote:

> On 2012.2.3 3:22 PM, Leon Timmermans wrote:
>> You shouldn't make it stop. «perl Build.PL» does configuration, not
>> building. Hence build or runtime requirements are not required to be
>> satisfied. What you're observing is not an error in any way, but an
>> essential step in the process. It gives the install tool the chance to
>> tell the cpan client (or the end user, if he's installing by hand) the
>> opportunity what dependencies to install.
>

> MakeMaker has something like what Alberto wants, PREREQ_FATAL. It's
> considered a misfeature for exactly the reasons above. It doesn't let the
> configuration step complete so tools cannot resolve the dependencies and
> continue building.
>
> Alberto, what are you trying to accomplish here? There's probably a way to do it.

Basically, I depend on Parse::Yapp, and I would like to call `yapp` on
Build.PL so I can have the generated .pm file before M::B generates all
its data dir.

In fact, I can add that to inc/MyBuilder.pm, but I am afraid the
generated .pm will not be installed.

But probably I am just too used to MakeMaker and M::B will work just fine :)

Cheers
ambs

[Leon Timmermans]

2012/2/4 Alberto Simões <al...@alfarrabio.di.uminho.pt>:

> Basically, I depend on Parse::Yapp, and I would like to call `yapp` on
> Build.PL so I can have the generated .pm file before M::B generates all its
> data dir.
>
> In fact, I can add that to inc/MyBuilder.pm, but I am afraid the generated
> .pm will not be installed.
>
> But probably I am just too used to MakeMaker and M::B will work just fine :)

There are two ways to do this. You can do this early enough during
build, the PL_files feature would be the most obvious way.
Alternatively you can add Parse::Yapp to configure requires (no need
to add a check for that, it will die by itself if it's missing), but
that will crap out on legacy perls without having any obvious
advantages.

Leon

[Leon Timmermans]

On Sat, Feb 4, 2012 at 1:32 AM, Adam Kennedy
<adamkenn...@gmail.com> wrote:
> While I agree it needs to finish, I do kind of wish dependencies could
> be enforced at the build module level so that tests couldn't run until
> dependencies are satisfied.

I tend to agree with that. I've been writting Test::CheckDeps
(warning: very much a 0.001 release) to make it crap out as early as
possible during testing, but it could be even earlier.

Leon

[David Golden]

Plenty of code has dependencies listed that aren't truly required and
tests will pass with lower versions.

The proper way to enforce dependencies is in a "use" statement:

use Foo::Bar 1.23;

Not coincidentally, that's how Dist::Zilla detects dependencies,
ensuring that code and specified prereqs are actually in sync.

In my view, other tools are doing it wrong.

-- David

[David Golden]

On Sat, Feb 4, 2012 at 5:17 PM, Adam Kennedy <ad...@ali.as> wrote:
> That's how Module::Install's requires_from does it too.
>
> I should look at zilla's code and see how it runs, might be worth
> aligning M:I and it's detection.

It uses Ricardo's Perl::PrereqScanner, which does a pretty sane job of
it (even detects base/parent and so on). It has some extensions for
picking up Moose and POE prereqs and so on.

It doesn't help with optional, dynamic prereqs so those have to be
specified manually, but that's unavoidable I think.

David

[David Golden]

On Sat, Feb 4, 2012 at 9:43 PM, Adam Kennedy <ad...@ali.as> wrote:
> If the goal is only to pick up versioned dependencies, I'm surprised
> we even need to bother with that.

It picks up as many "standard" dependencies as it can, but treats
anything without a version as requesting version 0.

-- David

[David Golden]

On Sat, Feb 4, 2012 at 9:51 PM, Adam Kennedy <ad...@ali.as> wrote:
> I was thinking about dropping anything without a specific numberic
> version completely and requiring manual, because I figure the chances
> for misidentification is too high (whereas a number will only really
> be there after a human has put some specific thought into it).

You're sort of talking about the equivalent of "use strict" for module
importing. (Though note that it can't be done via C<use parent
'Foo'>.)

I think that's a sensible strategy, though I think you'll annoy people
who really want it to DWIM rather than have to be explicit about it.

-- David

[Eric Wilhelm]

# from David Golden
# on Saturday 04 February 2012 17:23:

>It doesn't help with optional, dynamic prereqs so those have to be
>specified manually, but that's unavoidable I think.

I've experimented with detecting those using my Devel::TraceDeps on the
running test suite. It is possible to see the source and target of
every require(), including failed ones (so you have to be using
eval+require, but you already knew it was incorrect to go stat()ing
around in @INC looking for your optional deps.)

--Eric
--
software: a hypothetical exercise which happens to compile.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------

[David Golden]

On Sun, Feb 5, 2012 at 1:15 AM, Eric Wilhelm <enob...@gmail.com> wrote:
>>It doesn't help with optional, dynamic prereqs so those have to be
>>specified manually, but that's unavoidable I think.
>
> I've experimented with detecting those using my Devel::TraceDeps on the
> running test suite.  It is possible to see the source and target of
> every require(), including failed ones (so you have to be using
> eval+require, but you already knew it was incorrect to go stat()ing
> around in @INC looking for your optional deps.)

That's a different use case (though a neat trick). Seeing optional
dependency load attempts is different than knowing which ones should
be included in metadata (and whether they should be "recommends" or
"suggests" or omitted) and what version of them are required.

-- David

[Adam Kennedy]

That's how Module::Install's requires_from does it too.

I should look at zilla's code and see how it runs, might be worth
aligning M:I and it's detection.

Adam

[Adam Kennedy]

I was thinking about dropping anything without a specific numberic
version completely and requiring manual, because I figure the chances
for misidentification is too high (whereas a number will only really
be there after a human has put some specific thought into it).

Adam

[Adam Kennedy]

If the goal is only to pick up versioned dependencies, I'm surprised
we even need to bother with that.

For M:I I've been thinking of just scanning all of script and lib for
/^use Module::Name 1.23/ to determine requires, and all of t to find
build_requires/test_requires.

Anything loaded without a specific numeric version would be ignored
and would have to be specified with a manual requires statement.

I'd filter out POD and comment lines, but I wouldn't bother with full
source parsing (can't really do that inside M:I anyway since I'd have
to bundle PPI).

Adam