Can git choose perl at runtime?
- Date: Tue, 18 Dec 2018 22:09:14 -0500
- From: John Passaro <john.a.passaro@xxxxxxxxx>
- Subject: Can git choose perl at runtime?
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:
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
That does mean we have a new command to support and document: "git
perl". If it is preferred to keep this hidden as an implementation
detail, we could call the executable something like "util-git-perl"
instead so that it doesn't show up when scanning libexec for git
Does this seem like a good idea? I'd be happy to work on a patch.