Re: Git's Perl scripts can fail if user is configured for perlbrew

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sun, Dec 28, 2014 at 11:36 PM, Randy J. Ray <rjray@blackperl.com> wrote:
> I use git on MacOS via homebrew (http://brew.sh/), and a custom Perl
> installation built and managed via perlbrew (http://perlbrew.pl/). At some
> point, commands like "git add -i" broke. I say "at some point", because I'm
> not a git power-user and I only just noticed it this week.
>
> I am running Git 2.2.1 with a perlbrew'd Perl 5.20.1. When I would run "git
> add -i" (or "git add -p"), it would immediately die with a signal 11. Some
> poking around showed that those git commands that are implemented as Perl
> scripts run under /usr/bin/perl, and also prefix some directories to the
> module search-path. The problem stems from the fact that, when you are using
> perlbrew, you also have the PERL5LIB environment variable set. The contents
> of it lay between the git-provided paths and the default contents of @INC.
> When the Git module is loaded, it (eventually) triggers a load of
> List::Util, whose C-level code fails to load because of a version mismatch;
> you got List::Util from the paths in PERL5LIB, but it doesn't match the
> version of perl from /usr/bin/perl.
>
> After poking around and trying a few different things, I have found that
> using the following line in place of "#!/usr/bin/perl" solves this problem:
>
>         #!/usr/bin/env perl
>
> This can be done by defaulting PERL_PATH to "/usr/bin/env perl" in Makefile.
>
> I don't know enough about the overall git ecosystem to know if this would
> have an adverse effect on anything else (in particular, Windows
> compatibility, but then Windows probably isn't having this issue in the
> first place).
>
> I could just create and mail in the one-line patch for this, but I thought
> it might be better to open it up for some discussion first?

[CC'd the perlbrew author]

This is a bit of a tricky issue.

Using whatever perl is defined in the environment is just as likely to
break, in general the build process tries to pick these assets at
compile-time. Imagine you're experimenting with some custom perl
version and now Git inexplicably breaks.

It's better if Git detects a working perl when you compile it and
sticks with that, which is why we use /usr/bin/perl by default.

When you're setting PERL5LIB you're indicating to whatever perl
interpreter you're going to run that that's where they it should pick
up its modules. IMO they way perlbrew does this is broken, instead of
setting PATH + PERL5LIB globally for your login shell it should set
the PATH, and then the "perl" in that path should be a pointer to some
small shellscript that sets PERL5LIB for *its* perl.

I don't know what the right tradeoff here is, but I think it would be
just as sensible to unset PERL5LIB in our own perl scripts + modules,
it would make live monkeypatching when you wanted to harder, but we
could always add a GITPERL5LIB or something...