Re: Can git choose perl at runtime?

> On Tue, Dec 18, 2018 at 10:09:14PM -0500, John Passaro wrote:
>> I recently submitted my first patch using OSX and found the experience
>> frustrating, for reasons that have come up on the list before,
>> concerning git-send-email and perl dependencies that you need to be
>> root to update.
>>
>> Last seen here:
>> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/
>>
>> The struggle is that Mac's package manager Homebrew has opted,
>> apparently with some finality, to no longer support linking to a user
>> perl at build time. PERL_PATH is hard-coded to link to the system
>> perl, which means the user needs sudo to install the SSL libraries
>> required for send-email. So for send-email to work, you need to either
>> sudo cpan or build git yourself. The obvious solution here would be to
>> do /usr/bin/env perl, but in the above message Aevar pointed out
>> pitfalls with that.
>>
>> It seems that choosing perl at compile time necessarily comes with
>> tradeoffs. So I wonder if there is a way we can support choosing a
>> perl at runtime without breaking the existing mechanism of linking to
>> perl at compile time.
>>
>> I'm picturing adding an executable "git-perl" to libexec that checks
>> config core.perlPath and envvar GIT_PERL_PATH, in some order. Having
>> chosen one of these or the build-time PERL_PATH as a last resort, it
>> exec's the correct perl executable.
>>
>> Then relevant scripts (e.g. git-add--interactive, git-send-email)
>> invoke git-perl instead of /usr/bin/perl, and the makefile no longer
>> replaces that with PERL_PATH -- instead that will be used at runtime
>> via git-perl when we can be sure the user does not explicitly prefer
>> something different.
>
> How do git send-email and git svn work in such a case? They depend on
> the Git and Git::SVN modules being in place, so if you use a Perl other
> than the one you built Git with, they won't be present (or they'll be
> present, but potentially with the wrong version).