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

From: Randy J. Ray <rjray@blackperl.com>
Date: Dec 29, 2014, 21:07 UTC
Message-ID: <54A1C29C.4090100@blackperl.com>
In-Reply-To: <CACBZZX4qKyfRcbowYnM-KsrbKZ2=9RXr+HEgrOU1jaCsSX53QA@mail.gmail.com>

On 12/29/14, 7:21 AM, Ævar Arnfjörð Bjarmason wrote:

Show 11 quoted lines

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

These are good points. I'm not sure when this stopped working for me... I don't use the -i or -p options to "git add" very often. So I can't say at what point it stopped working with the current configuration, only that it "used to work".

Show 6 quoted lines

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

That would be for the perlbrew author to consider, of course.

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

You would have to have a shell script that un-set PERL5LIB and then invoked the given git script, because by the time script execution has begun, the contents of PERL5LIB have already been added to the head of the list of search paths. One approach I tried was to set the environment variable GITPERLLIB (which you already use and recognize, so there is no need for GITPERL5LIB), but that did not help. The base problem still remained: The content of PERL5LIB (which pointed to 5.20.1-compiled extensions) took priority over the default @INC contents (which were for a 5.16.2 perl).

I don't know the right trade-off, either. I started out reporting this as an issue against the homebrew project's recipe for git, because they actually add more explicit library paths to @INC than a vanilla build/install of git does. But the problem is really in the interaction between /usr/bin/perl and a PERL5LIB set for an alternate perl. So the solution, if there is one, will lay here in git somewhere...

Randy

-- 
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Randy J. Ray      Sunnyvale, CA      http://www.dereferenced.com
rjray@blackperl.com
twitter.com/rjray
Silicon Valley Scale Modelers: http://www.svsm.org