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

From: Eric Wong <e@80x24.org>
Date: Jan 14, 2017, 10:31 UTC
Message-ID: <20170114103134.GA586@untitled>
In-Reply-To: <20170114075408.hyidkb4rzxzmm2je@sigill.intra.peff.net>

Jeff King <peff@peff.net> wrote:

Show 6 quoted lines

> 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).

Every user is a potential developer(*). And I do feel we (git developers) should be at least somewhat responsible for helping maintain and fix the projects we depend on; or moving to alternatives if we can't fix them.

There is a chance a newly-introduced warning in a 3rd-party module points to a real problem with the way git uses it, too. Having that warning would help us fix or workaround the bug (either in git or the module).

I doubt any module author would be unresponsive to having a localized "no warnings" for special cases. AFAIK, "-w" is widespread amongst Perl users (unlike Ruby in my experience).

(*) I feel that more strongly in the git case, and even more so
    for the Perl bits since the source is already on the user's
    machine.

> 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?

I'm not saying we blindly start using '-w' everywhere today.
But we may at least try it and see if it introduces new
warnings, first, and only enable '-w' when it it looks quiet
(and perhaps start working with module authors to fix warnings
 if not).

As a user, I'd rather have some indication of where something might be wrong, than no warning at all when something does go wrong.