Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

[Jeff King <peff@peff.net>]

On Fri, Jan 13, 2017 at 06:52:46PM +0000, Eric Wong wrote:

> > If something we _use_ from a third-party is not warnings-clean,
> > there is no easy way to squelch them if we use "-w", which is a
> > potential downside, isn't it?  I do not know how serious a problem
> > it is in practice.  I suspect that the core package we use from perl
> > distribution are supposed to be warnings-clean, but we use a handful
> > of things from outside the core and I do not know what state they
> > are in.
> 
> Yes, "-w" will trigger warnings in third party packages.
> Existing uses we have should be fine, and I think most Perl
> modules we use or would use are vigilant about being
> warnings-clean.  If we have to leave off a "-w", there should
> probably be a comment at the top stating the reason:
> 
> #!/usr/bin/perl
> # Not using "perl -w" since Foo::Bar <= X.Y.Y is not warnings-clean
> use strict;
> use warnings;
> use Foo::Bar;
> ...

Just as a devil's advocate, why do we care about warnings in third-party
modules? Or more specifically, why do _users_ who are running Git care
about them? We cannot fix them in Git. A user may report the error to
the module author, but the module author may not be responsive, or even
may not be inclined to fix the problem (because they have a particular
opinion on that warning).

In the meantime, the user is stuck with an annoying warning message
until Git is updated as you showed above. Why not just start there
preemptively, and let module authors worry about their own warnings?

-Peff