On Fri, Dec 21 2018, brian m. carlson wrote: > On Tue, Dec 18, 2018 at 10:09:14PM -0500, John Passaro 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. >> >> Last seen here: >> https://public-inbox.org/git/878t55qga6.fsf@xxxxxxxxxxxxxxxxxxx/ >> >> The struggle is that Mac's package manager Homebrew has opted, >> apparently with some finality, to no longer support linking to a user >> perl at build time. PERL_PATH is hard-coded to link to the system >> perl, which means the user needs sudo to install the SSL libraries >> required for send-email. So for send-email to work, you need to either >> sudo cpan or build git yourself. The obvious solution here would be to >> do /usr/bin/env perl, but in the above message Aevar pointed out >> pitfalls with that. >> >> It seems that choosing perl at compile time necessarily comes with >> tradeoffs. So I wonder if there is a way we can support choosing a >> perl at runtime without breaking the existing mechanism of linking to >> perl at compile time. >> >> I'm picturing adding an executable "git-perl" to libexec that checks >> config core.perlPath and envvar GIT_PERL_PATH, in some order. Having >> chosen one of these or the build-time PERL_PATH as a last resort, it >> exec's the correct perl executable. >> >> Then relevant scripts (e.g. git-add--interactive, git-send-email) >> invoke git-perl instead of /usr/bin/perl, and the makefile no longer >> replaces that with PERL_PATH -- instead that will be used at runtime >> via git-perl when we can be sure the user does not explicitly prefer >> something different. > > How do git send-email and git svn work in such a case? They depend on > the Git and Git::SVN modules being in place, so if you use a Perl other > than the one you built Git with, they won't be present (or they'll be > present, but potentially with the wrong version). Yeah this is one of the things I was alluding to in <87a7l1fx8x.fsf@xxxxxxxxxxxxxxxxxxx>. We don't ship any C bindings, so our libs end up in e.g. /usr/share/perl5, some custom-built perls will have that in their @INC still, no idea if any of this OSX stuff does. But otherwise we'd either need to give the user a way to override PERL5LIB (or they can do it themselves...), or better yet continue what I started in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10) and make our perl stuff entirely decoupled from the system install. E.g. Linux distros would probably still override that and install our *.pm stuff in their usual Perl places, but by default we could just have a libexec/perl directory with all this stuff, and find our libraries there, then it won't matter if we chainload to a new Perl interpreter, we'll still find the libs in the same place. We could also turn RUNTIME_PREFIX on by default, it already fixes this by proxy.
