On Wed, Dec 19 2018, Carlo Arenas wrote:
> On Tue, Dec 18, 2018 at 7:29 PM John Passaro <john.a.passaro@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx/
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....
