Re: Can git choose perl at runtime?
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Dec 19, 2018, 13:53 UTC
- Message-ID
- <878t0lfwrj.fsf@evledraar.gmail.com>
- In-Reply-To
- <CAPUEspgw2xYxNQN-0_nqQrWE4jhmMN-9aHgJ8NvLDcEKTrZNAw@mail.gmail.com>
On Wed, Dec 19 2018, Carlo Arenas wrote:
Show 10 quoted lines
> 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....