Randy W. Sims wrote:
Adam Kennedy wrote:
>> There are a number of ways to do this. The most simple is:
>>
>> use strict;
>> use warnings;
>>
>> use File::HomeDir;
>> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' );
>
>
> Not that I wish to be a pedant about this, but only so people keep it in
> mind...
>
> This installer will crash with a non-useful error message if someone
> tries to install of < 5.006, and has an implicit undeclared (still
> unresolvable I believe) dependency on File::HomeDir.
How is this different from a Makefile.PL or any other perl script with a
C<use> statement. If the C<use>d module can't be found, it says it can't
be found. It doesn't crash.
There is no difference at all when it comes to Makefile.PL.
The problem is specific to installers. In an installer, you don't yet
know if any piece of code is SUPPOSED to run, as well as not know if it
will run.
While the code for the distribution might be able to die like this, the
INSTALLER should fail in a way that is detectable and automatable.
If the C<use>d warnings.pm module can't be found, it crashes
(specifically, dies) and say it can't find warnings. But the problem
isn't that it doesn't have warnings. The problem is that it doesn't have
Perl 5.006.
If the installer needs a module in order to run, it has nothing to fall
back on to supply that module for it. Any surrounding client doing a
recursive installation can't fix it, unless what it can do when the
installer runs and says that the distribution itself needs dependencies.
If the installer doesn't look after itself, then we are back to the
situation where you are installing RT, and half way though 3000 lines of
output something goes BLART NO WARNINGS.PM, INSTALL FAILED and then
prints another 1000 lines of output, and no reasonable end users has any
idea whatsoever what caused the problem, or how to fix it.
If an installer can't INSTALL under battle conditions, it is failing
it's primary missing.
Adam K
Sure, the dependency should be listed in META.yml. And, there is a way
to that so that CPAN.pm and other tools can see the dependency before
running the Build.PL: You simply list it in C<requres> argument to the
constructor. But this was just a simplified example to illustrate a
different point...
> (I'll shut up about the whole implicit undeclared unresolvable
> dependency on Module::Build for a while, given it's now in the core and
> I've had a good long chat about the issue with Tony.)
Again, how is this different from MakeMaker's Makefile.PL which, strange
enough, requires MakeMaker to be present?
> So if you use warnings in your Build.PL you should always do it as
>
> use 5.006;
> use strict;
> use warnings;
I agree, this is true of any script, not just Build.PL.
> As for how to ensure File::HomeDir is installed before you actually know
> what you dependencies are, well I dunno, but this problem is going to
> keep coming back and haunting us till MB supports bundling of some kind.
Bundling is *a* solution to *some* problems *some* of the time. From
what I understand there's a pretty good module out there that helps with
that ;). But I'm not yet convinced that it should be the default method
for every distribution. Authors should have a choice. For people who
want to bundle Module::Build it's simple to do by hand, and it's been
done by authors who decided that was best for their distribution.
Regards,
Randy.
