Re: Can git choose perl at runtime?

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

On Wed, Dec 19 2018, Carlo Arenas wrote:

> On Tue, Dec 18, 2018 at 7:29 PM John Passaro <john.a.passaro@gmail.com> 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.
>
> you can install them somewhere else (your homedir, for example) and
> then instruct perl to look for them there by setting the PERL5LIB
> environment variable

Note that this is different. Cases I can think of:

 1. You have an entirely different perl + modules somewhere. E.g. maybe
    on OSX /usr/bin/perl v.s. some homebrew version of perl+CPAN. My WIP
    https://public-inbox.org/git/87a7l1fx8x.fsf@evledraar.gmail.com/
    addresses this.

 2. You're happy with /usr/bin/perl (or whatever git is compiled with),
    but miss some module(s). That's your suggestion here, but note that
    in this case you usually need a compiler (E-Mail SSL libs etc.),
    which may not be what the user wants.

    I.e. they can install a new perl+modules from their package manager
    easily, but can't as easily build their own modules for a system
    perl.

 3. Using a /usr/bin/perl + e.g. homebrew CPAN libs via a "modules over
    here" facility similar to #2 is likely to segfault (different ABI
    versions).

I think we're good if we just have #1 and if people have the #2 use-case
an additional core.perlLibs config of stuff to prepend to @INC (or maybe
entirly override, least we run into the segfault case in #3).

For that last bit see also 7a7bfc7adc ("perl: treat PERLLIB_EXTRA as an
extra path again", 2018-01-02). I.e. there's the use case of "@INC
instead of" and "@INC extra".

But probably you're happy with just #1 for now....