On Wed, Dec 19 2018, 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@xxxxxxxxxxxxxxxxxxx/ > > 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. > > 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 > commands. > > Does this seem like a good idea? I'd be happy to work on a patch. I see no problem with this. As I noted in my message you linked to doing this unconditionally is a bad idea, but we can just do it with a config, e.g. this works: diff --git a/perl/header_templates/fixed_prefix.template.pl b/perl/header_templates/fixed_prefix.template.pl index 857b4391a4..f96e2ecd11 100644 --- a/perl/header_templates/fixed_prefix.template.pl +++ b/perl/header_templates/fixed_prefix.template.pl @@ -1 +1,7 @@ +BEGIN { + chomp(my $perlPath = `git config --get core.perlPath`);; + if ($perlPath and $^X ne $perlPath) { + exec($perlPath, $0, @ARGV); + } +} use lib (split(/@@PATHSEP@@/, $ENV{GITPERLLIB} || '@@INSTLIBDIR@@')); Here you just optionally set core.perlPath in your config and if set it'll chainload to the new interpreter you point at. I leave wondering if you also want a setting for @INC there, dealing with perl/header_templates/runtime_prefix.template.pl and docs/tests as an exercise for the reader :)
