{"thread":{"id":"50063","subject":"Can git choose perl at runtime?","startedAt":"2018-12-19T03:11:17Z","lastAt":"2018-12-28T15:39:34Z","messageCount":11,"participants":["John Passaro","Jonathan Nieder","Carlo Arenas","Ævar Arnfjörð Bjarmason","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"365560","messageId":"CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com","threadId":"50063","inReplyTo":null,"subject":"Can git choose perl at runtime?","fromName":"John Passaro","fromEmail":"john.a.passaro@gmail.com","sentAt":"2018-12-19T03:09:14Z","receivedAt":"2018-12-19T03:11:17Z","isPatch":false,"sender":{"key":"john.a.passaro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6754005?v=4"},"body":"I recently submitted my first patch using OSX and found the experience\nfrustrating, for reasons that have come up on the list before,\nconcerning git-send-email and perl dependencies that you need to be\nroot to update.\n\nLast seen here:\nhttps://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/\n\nThe struggle is that Mac's package manager Homebrew has opted,\napparently with some finality, to no longer support linking to a user\nperl at build time. PERL_PATH is hard-coded to link to the system\nperl, which means the user needs sudo to install the SSL libraries\nrequired for send-email. So for send-email to work, you need to either\nsudo cpan or build git yourself. The obvious solution here would be to\ndo /usr/bin/env perl, but in the above message Aevar pointed out\npitfalls with that.\n\nIt seems that choosing perl at compile time necessarily comes with\ntradeoffs. So I wonder if there is a way we can support choosing a\nperl at runtime without breaking the existing mechanism of linking to\nperl at compile time.\n\nI'm picturing adding an executable \"git-perl\" to libexec that checks\nconfig core.perlPath and envvar GIT_PERL_PATH, in some order. Having\nchosen one of these or the build-time PERL_PATH as a last resort, it\nexec's the correct perl executable.\n\nThen relevant scripts (e.g. git-add--interactive, git-send-email)\ninvoke git-perl instead of /usr/bin/perl, and the makefile no longer\nreplaces that with PERL_PATH -- instead that will be used at runtime\nvia git-perl when we can be sure the user does not explicitly prefer\nsomething different.\n\nThat does mean we have a new command to support and document: \"git\nperl\". If it is preferred to keep this hidden as an implementation\ndetail, we could call the executable something like \"util-git-perl\"\ninstead so that it doesn't show up when scanning libexec for git\ncommands.\n\nDoes this seem like a good idea? I'd be happy to work on a patch.\n"},{"id":"365561","messageId":"20181219031752.GA181843@google.com","threadId":"50063","inReplyTo":"CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com","subject":"Re: Can git choose perl at runtime?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-12-19T03:17:52Z","receivedAt":"2018-12-19T03:17:57Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi John,\n\nJohn Passaro wrote:\n\n> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/\n>\n> The struggle is that Mac's package manager Homebrew has opted,\n> apparently with some finality, to no longer support linking to a user\n> perl at build time. PERL_PATH is hard-coded to link to the system\n> perl, which means the user needs sudo to install the SSL libraries\n> required for send-email. So for send-email to work, you need to either\n> sudo cpan or build git yourself. The obvious solution here would be to\n> do /usr/bin/env perl, but in the above message Aevar pointed out\n> pitfalls with that.\n>\n> It seems that choosing perl at compile time necessarily comes with\n> tradeoffs. So I wonder if there is a way we can support choosing a\n> perl at runtime without breaking the existing mechanism of linking to\n> perl at compile time.\n\nI haven't carefully looked at your exact proposal, but I just wanted\nto offer you my support: yes, I would love to see some solution.\nThanks for looking into it.\n\nIt would let me remove this bit of horror from my local build script:\n\n APIVER_EXPR='@{[sub{use Config; $$Config{api_version}}->()]}'\n XCODE_PERL=\"/Applications/Xcode.app/Contents/Developer/Library/Perl/5.$APIVER_EXPR/darwin-thread-multi-2level\"\n make ... PERLLIB_EXTRA=\"$XCODE_PERL\"\n\n(My apologies.)\n\n[...]\n> That does mean we have a new command to support and document: \"git\n> perl\". If it is preferred to keep this hidden as an implementation\n> detail, we could call the executable something like \"util-git-perl\"\n> instead so that it doesn't show up when scanning libexec for git\n> commands.\n\nTypically we handle this kind of thing by putting a double-dash in\nthe command name.  See git-sh--setup, for example.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"365564","messageId":"CAPUEspgw2xYxNQN-0_nqQrWE4jhmMN-9aHgJ8NvLDcEKTrZNAw@mail.gmail.com","threadId":"50063","inReplyTo":"CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com","subject":"Re: Can git choose perl at runtime?","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2018-12-19T06:33:00Z","receivedAt":"2018-12-19T06:33:16Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Tue, Dec 18, 2018 at 7:29 PM John Passaro <john.a.passaro@gmail.com> wrote:\n>\n> I recently submitted my first patch using OSX and found the experience\n> frustrating, for reasons that have come up on the list before,\n> concerning git-send-email and perl dependencies that you need to be\n> root to update.\n\nyou can install them somewhere else (your homedir, for example) and\nthen instruct perl to look for them there by setting the PERL5LIB\nenvironment variable\n\nCarlo\n"},{"id":"365573","messageId":"87a7l1fx8x.fsf@evledraar.gmail.com","threadId":"50063","inReplyTo":"CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com","subject":"Re: Can git choose perl at runtime?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-19T13:43:10Z","receivedAt":"2018-12-19T13:43:08Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Dec 19 2018, John Passaro wrote:\n\n> I recently submitted my first patch using OSX and found the experience\n> frustrating, for reasons that have come up on the list before,\n> concerning git-send-email and perl dependencies that you need to be\n> root to update.\n>\n> Last seen here:\n> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/\n>\n> The struggle is that Mac's package manager Homebrew has opted,\n> apparently with some finality, to no longer support linking to a user\n> perl at build time. PERL_PATH is hard-coded to link to the system\n> perl, which means the user needs sudo to install the SSL libraries\n> required for send-email. So for send-email to work, you need to either\n> sudo cpan or build git yourself. The obvious solution here would be to\n> do /usr/bin/env perl, but in the above message Aevar pointed out\n> pitfalls with that.\n>\n> It seems that choosing perl at compile time necessarily comes with\n> tradeoffs. So I wonder if there is a way we can support choosing a\n> perl at runtime without breaking the existing mechanism of linking to\n> perl at compile time.\n>\n> I'm picturing adding an executable \"git-perl\" to libexec that checks\n> config core.perlPath and envvar GIT_PERL_PATH, in some order. Having\n> chosen one of these or the build-time PERL_PATH as a last resort, it\n> exec's the correct perl executable.\n>\n> Then relevant scripts (e.g. git-add--interactive, git-send-email)\n> invoke git-perl instead of /usr/bin/perl, and the makefile no longer\n> replaces that with PERL_PATH -- instead that will be used at runtime\n> via git-perl when we can be sure the user does not explicitly prefer\n> something different.\n>\n> That does mean we have a new command to support and document: \"git\n> perl\". If it is preferred to keep this hidden as an implementation\n> detail, we could call the executable something like \"util-git-perl\"\n> instead so that it doesn't show up when scanning libexec for git\n> commands.\n>\n> Does this seem like a good idea? I'd be happy to work on a patch.\n\nI see no problem with this. As I noted in my message you linked to doing\nthis unconditionally is a bad idea, but we can just do it with a config,\ne.g. this works:\n\n    diff --git a/perl/header_templates/fixed_prefix.template.pl b/perl/header_templates/fixed_prefix.template.pl\n    index 857b4391a4..f96e2ecd11 100644\n    --- a/perl/header_templates/fixed_prefix.template.pl\n    +++ b/perl/header_templates/fixed_prefix.template.pl\n    @@ -1 +1,7 @@\n    +BEGIN {\n    +    chomp(my $perlPath = `git config --get core.perlPath`);;\n    +    if ($perlPath and $^X ne $perlPath) {\n    +       exec($perlPath, $0, @ARGV);\n    +    }\n    +}\n     use lib (split(/@@PATHSEP@@/, $ENV{GITPERLLIB} || '@@INSTLIBDIR@@'));\n\nHere you just optionally set core.perlPath in your config and if set\nit'll chainload to the new interpreter you point at.\n\nI leave wondering if you also want a setting for @INC there, dealing\nwith perl/header_templates/runtime_prefix.template.pl and docs/tests as\nan exercise for the reader :)\n"},{"id":"365574","messageId":"878t0lfwrj.fsf@evledraar.gmail.com","threadId":"50063","inReplyTo":"CAPUEspgw2xYxNQN-0_nqQrWE4jhmMN-9aHgJ8NvLDcEKTrZNAw@mail.gmail.com","subject":"Re: Can git choose perl at runtime?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-19T13:53:36Z","receivedAt":"2018-12-19T13:53:32Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Dec 19 2018, Carlo Arenas wrote:\n\n> On Tue, Dec 18, 2018 at 7:29 PM John Passaro <john.a.passaro@gmail.com> wrote:\n>>\n>> I recently submitted my first patch using OSX and found the experience\n>> frustrating, for reasons that have come up on the list before,\n>> concerning git-send-email and perl dependencies that you need to be\n>> root to update.\n>\n> you can install them somewhere else (your homedir, for example) and\n> then instruct perl to look for them there by setting the PERL5LIB\n> environment variable\n\nNote that this is different. Cases I can think of:\n\n 1. You have an entirely different perl + modules somewhere. E.g. maybe\n    on OSX /usr/bin/perl v.s. some homebrew version of perl+CPAN. My WIP\n    https://public-inbox.org/git/87a7l1fx8x.fsf@evledraar.gmail.com/\n    addresses this.\n\n 2. You're happy with /usr/bin/perl (or whatever git is compiled with),\n    but miss some module(s). That's your suggestion here, but note that\n    in this case you usually need a compiler (E-Mail SSL libs etc.),\n    which may not be what the user wants.\n\n    I.e. they can install a new perl+modules from their package manager\n    easily, but can't as easily build their own modules for a system\n    perl.\n\n 3. Using a /usr/bin/perl + e.g. homebrew CPAN libs via a \"modules over\n    here\" facility similar to #2 is likely to segfault (different ABI\n    versions).\n\nI think we're good if we just have #1 and if people have the #2 use-case\nan additional core.perlLibs config of stuff to prepend to @INC (or maybe\nentirly override, least we run into the segfault case in #3).\n\nFor that last bit see also 7a7bfc7adc (\"perl: treat PERLLIB_EXTRA as an\nextra path again\", 2018-01-02). I.e. there's the use case of \"@INC\ninstead of\" and \"@INC extra\".\n\nBut probably you're happy with just #1 for now....\n"},{"id":"365753","messageId":"20181221234231.GB10611@genre.crustytoothpaste.net","threadId":"50063","inReplyTo":"CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com","subject":"Re: Can git choose perl at runtime?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-12-21T23:42:31Z","receivedAt":"2018-12-21T23:42:39Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Dec 18, 2018 at 10:09:14PM -0500, John Passaro wrote:\n> I recently submitted my first patch using OSX and found the experience\n> frustrating, for reasons that have come up on the list before,\n> concerning git-send-email and perl dependencies that you need to be\n> root to update.\n> \n> Last seen here:\n> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/\n> \n> The struggle is that Mac's package manager Homebrew has opted,\n> apparently with some finality, to no longer support linking to a user\n> perl at build time. PERL_PATH is hard-coded to link to the system\n> perl, which means the user needs sudo to install the SSL libraries\n> required for send-email. So for send-email to work, you need to either\n> sudo cpan or build git yourself. The obvious solution here would be to\n> do /usr/bin/env perl, but in the above message Aevar pointed out\n> pitfalls with that.\n> \n> It seems that choosing perl at compile time necessarily comes with\n> tradeoffs. So I wonder if there is a way we can support choosing a\n> perl at runtime without breaking the existing mechanism of linking to\n> perl at compile time.\n> \n> I'm picturing adding an executable \"git-perl\" to libexec that checks\n> config core.perlPath and envvar GIT_PERL_PATH, in some order. Having\n> chosen one of these or the build-time PERL_PATH as a last resort, it\n> exec's the correct perl executable.\n> \n> Then relevant scripts (e.g. git-add--interactive, git-send-email)\n> invoke git-perl instead of /usr/bin/perl, and the makefile no longer\n> replaces that with PERL_PATH -- instead that will be used at runtime\n> via git-perl when we can be sure the user does not explicitly prefer\n> something different.\n\nHow do git send-email and git svn work in such a case? They depend on\nthe Git and Git::SVN modules being in place, so if you use a Perl other\nthan the one you built Git with, they won't be present (or they'll be\npresent, but potentially with the wrong version).\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"365762","messageId":"87y38few5h.fsf@evledraar.gmail.com","threadId":"50063","inReplyTo":"20181221234231.GB10611@genre.crustytoothpaste.net","subject":"Re: Can git choose perl at runtime?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-23T22:05:46Z","receivedAt":"2018-12-23T22:05:51Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Dec 21 2018, brian m. carlson wrote:\n\n> On Tue, Dec 18, 2018 at 10:09:14PM -0500, John Passaro wrote:\n>> I recently submitted my first patch using OSX and found the experience\n>> frustrating, for reasons that have come up on the list before,\n>> concerning git-send-email and perl dependencies that you need to be\n>> root to update.\n>>\n>> Last seen here:\n>> https://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/\n>>\n>> The struggle is that Mac's package manager Homebrew has opted,\n>> apparently with some finality, to no longer support linking to a user\n>> perl at build time. PERL_PATH is hard-coded to link to the system\n>> perl, which means the user needs sudo to install the SSL libraries\n>> required for send-email. So for send-email to work, you need to either\n>> sudo cpan or build git yourself. The obvious solution here would be to\n>> do /usr/bin/env perl, but in the above message Aevar pointed out\n>> pitfalls with that.\n>>\n>> It seems that choosing perl at compile time necessarily comes with\n>> tradeoffs. So I wonder if there is a way we can support choosing a\n>> perl at runtime without breaking the existing mechanism of linking to\n>> perl at compile time.\n>>\n>> I'm picturing adding an executable \"git-perl\" to libexec that checks\n>> config core.perlPath and envvar GIT_PERL_PATH, in some order. Having\n>> chosen one of these or the build-time PERL_PATH as a last resort, it\n>> exec's the correct perl executable.\n>>\n>> Then relevant scripts (e.g. git-add--interactive, git-send-email)\n>> invoke git-perl instead of /usr/bin/perl, and the makefile no longer\n>> replaces that with PERL_PATH -- instead that will be used at runtime\n>> via git-perl when we can be sure the user does not explicitly prefer\n>> something different.\n>\n> How do git send-email and git svn work in such a case? They depend on\n> the Git and Git::SVN modules being in place, so if you use a Perl other\n> than the one you built Git with, they won't be present (or they'll be\n> present, but potentially with the wrong version).\n\nYeah this is one of the things I was alluding to in\n<87a7l1fx8x.fsf@evledraar.gmail.com>.\n\nWe don't ship any C bindings, so our libs end up in\ne.g. /usr/share/perl5, some custom-built perls will have that in their\n@INC still, no idea if any of this OSX stuff does.\n\nBut otherwise we'd either need to give the user a way to override\nPERL5LIB (or they can do it themselves...), or better yet continue what\nI started in 20d2a30f8f (\"Makefile: replace perl/Makefile.PL with simple\nmake rules\", 2017-12-10) and make our perl stuff entirely decoupled from\nthe system install.\n\nE.g. Linux distros would probably still override that and install our\n*.pm stuff in their usual Perl places, but by default we could just have\na libexec/perl directory with all this stuff, and find our libraries\nthere, then it won't matter if we chainload to a new Perl interpreter,\nwe'll still find the libs in the same place.\n\nWe could also turn RUNTIME_PREFIX on by default, it already fixes this\nby proxy.\n"},{"id":"365764","messageId":"20181223231834.GD26554@genre.crustytoothpaste.net","threadId":"50063","inReplyTo":"87y38few5h.fsf@evledraar.gmail.com","subject":"Re: Can git choose perl at runtime?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-12-23T23:18:34Z","receivedAt":"2018-12-23T23:18:43Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sun, Dec 23, 2018 at 11:05:46PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Fri, Dec 21 2018, brian m. carlson wrote:\n> > How do git send-email and git svn work in such a case? They depend on\n> > the Git and Git::SVN modules being in place, so if you use a Perl other\n> > than the one you built Git with, they won't be present (or they'll be\n> > present, but potentially with the wrong version).\n> \n> Yeah this is one of the things I was alluding to in\n> <87a7l1fx8x.fsf@evledraar.gmail.com>.\n> \n> We don't ship any C bindings, so our libs end up in\n> e.g. /usr/share/perl5, some custom-built perls will have that in their\n> @INC still, no idea if any of this OSX stuff does.\n> \n> But otherwise we'd either need to give the user a way to override\n> PERL5LIB (or they can do it themselves...), or better yet continue what\n> I started in 20d2a30f8f (\"Makefile: replace perl/Makefile.PL with simple\n> make rules\", 2017-12-10) and make our perl stuff entirely decoupled from\n> the system install.\n> \n> E.g. Linux distros would probably still override that and install our\n> *.pm stuff in their usual Perl places, but by default we could just have\n> a libexec/perl directory with all this stuff, and find our libraries\n> there, then it won't matter if we chainload to a new Perl interpreter,\n> we'll still find the libs in the same place.\n\nThis wouldn't fix the fact that we still need modules like Net::SMTP,\nAuthen::SASL, and IO::Socket::SSL (because these days every provider\nforces TLS on the submission port). Since those are going to come from\nthe distributor, letting people override the Perl path to some arbitrary\npath will mean that those modules may not be installed.\n\nI also think that the situation you want with relocatable modules is\nonly going to be useful for people who custom-install their own Git,\nwhich is not most people. Nobody shipping a packaged version of Git is\ngoing to install modules in a custom Git-specific path (since they can't\nbe loaded by other software), so everyone who want to use a custom Perl\nwill already be compiling a custom Git and can just specify the Perl\nthey want to use.\n\nMy concern is, more generally, that this situation is going to lead to\nhard-to-troubleshoot user support issues. I routinely answer questions\non Stack Overflow and I see all sorts of cases where users who may be\ngreat programmers but are mostly unfamiliar with Git end up in bad\nsituations.\n\nFor example, at a previous job, we shipped a newer Git and Perl, which\nwere installed in a custom path (so definitely not using relocatable\nmodules). If this option were enabled and user used the newer Git, which\nwas installed in a custom path, but the system Perl, things would\ndefinitely be broken, since the system Perl would almost certainly have\nnone of the right modules (or, if it did, they'd be grossly out of\ndate). A lot of the users who would run into this issue are less\ntechnical, and so wouldn't know how to fix it.\n\nWe've traditionally shied away from specifying things like\n\"#!/usr/bin/env perl\" specifically for this reason: because people will\noften have custom-compiled versions of interpreters that don't meet our\nneeds. I'm not seeing how this is significantly different.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"365766","messageId":"87wonzes23.fsf@evledraar.gmail.com","threadId":"50063","inReplyTo":"20181223231834.GD26554@genre.crustytoothpaste.net","subject":"Re: Can git choose perl at runtime?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-23T23:34:12Z","receivedAt":"2018-12-23T23:34:19Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Dec 23 2018, brian m. carlson wrote:\n\n> On Sun, Dec 23, 2018 at 11:05:46PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> On Fri, Dec 21 2018, brian m. carlson wrote:\n>> > How do git send-email and git svn work in such a case? They depend on\n>> > the Git and Git::SVN modules being in place, so if you use a Perl other\n>> > than the one you built Git with, they won't be present (or they'll be\n>> > present, but potentially with the wrong version).\n>>\n>> Yeah this is one of the things I was alluding to in\n>> <87a7l1fx8x.fsf@evledraar.gmail.com>.\n>>\n>> We don't ship any C bindings, so our libs end up in\n>> e.g. /usr/share/perl5, some custom-built perls will have that in their\n>> @INC still, no idea if any of this OSX stuff does.\n>>\n>> But otherwise we'd either need to give the user a way to override\n>> PERL5LIB (or they can do it themselves...), or better yet continue what\n>> I started in 20d2a30f8f (\"Makefile: replace perl/Makefile.PL with simple\n>> make rules\", 2017-12-10) and make our perl stuff entirely decoupled from\n>> the system install.\n>>\n>> E.g. Linux distros would probably still override that and install our\n>> *.pm stuff in their usual Perl places, but by default we could just have\n>> a libexec/perl directory with all this stuff, and find our libraries\n>> there, then it won't matter if we chainload to a new Perl interpreter,\n>> we'll still find the libs in the same place.\n>\n> This wouldn't fix the fact that we still need modules like Net::SMTP,\n> Authen::SASL, and IO::Socket::SSL (because these days every provider\n> forces TLS on the submission port). Since those are going to come from\n> the distributor, letting people override the Perl path to some arbitrary\n> path will mean that those modules may not be installed.\n\nYeah, but my reading (which may be wrong) of John Passaro's E-Mail\nupthread\n(<CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com>)\nis that for some users this is the path of least resistance to getting\ngit-send-email et al working for whatever reason.\n\nI.e. they'd like to install a git version that's compiled against\n/usr/bin/perl, and then after the fact ask git to point to some other\nbetter working perl installation with all of the above compiled.\n\n> I also think that the situation you want with relocatable modules is\n> only going to be useful for people who custom-install their own Git,\n> which is not most people. Nobody shipping a packaged version of Git is\n> going to install modules in a custom Git-specific path (since they can't\n> be loaded by other software), so everyone who want to use a custom Perl\n> will already be compiling a custom Git and can just specify the Perl\n> they want to use.\n\nI mean that we could just make RUNTIME_PREFIX our default behavior, it\nwould simplify things by only carrying one \"how do we find stuff\" mode,\nand in this case nicely solve this whole problem of your custom perl not\nhaving git's perl modules in its @INC (but having everything else,\ne.g. Authen::SASL available).\n\n> My concern is, more generally, that this situation is going to lead to\n> hard-to-troubleshoot user support issues. I routinely answer questions\n> on Stack Overflow and I see all sorts of cases where users who may be\n> great programmers but are mostly unfamiliar with Git end up in bad\n> situations.\n>\n> For example, at a previous job, we shipped a newer Git and Perl, which\n> were installed in a custom path (so definitely not using relocatable\n> modules). If this option were enabled and user used the newer Git, which\n> was installed in a custom path, but the system Perl, things would\n> definitely be broken, since the system Perl would almost certainly have\n> none of the right modules (or, if it did, they'd be grossly out of\n> date). A lot of the users who would run into this issue are less\n> technical, and so wouldn't know how to fix it.\n\nNo comment on this other than: \"whoever's itch this actually is and who\npicks up my POC patch will need to address this to brian's satisfaction\"\n:)\n\n> We've traditionally shied away from specifying things like\n> \"#!/usr/bin/env perl\" specifically for this reason: because people will\n> often have custom-compiled versions of interpreters that don't meet our\n> needs. I'm not seeing how this is significantly different.\n\nBecause \"#!/usr/bin/env perl\" would break git if you were just playing\naround with a custom perl for some other reason, e.g. perl web\ndevelopment. I agree that this wouldn't be acceptable (as see in my\nhttps://public-inbox.org/git/878t55qga6.fsf@evledraar.gmail.com/ that\nJohn linked to).\n\nWhereas what's being proposed here is some way to specifically tell git\nvia configuration that it should use a runtime configured perl instead\nof the compile-time one.\n"},{"id":"365770","messageId":"20181224022042.GE26554@genre.crustytoothpaste.net","threadId":"50063","inReplyTo":"87wonzes23.fsf@evledraar.gmail.com","subject":"Re: Can git choose perl at runtime?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-12-24T02:20:42Z","receivedAt":"2018-12-24T02:20:57Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Dec 24, 2018 at 12:34:12AM +0100, Ævar Arnfjörð Bjarmason wrote:\n> Yeah, but my reading (which may be wrong) of John Passaro's E-Mail\n> upthread\n> (<CAJdN7Kioa22xrDP2ssZXmBbu7KDkcr2MQCUDW=Tzm5ydzeChBQ@mail.gmail.com>)\n> is that for some users this is the path of least resistance to getting\n> git-send-email et al working for whatever reason.\n\nI think we should just ask Homebrew to ship a functional, complete Git.\nIf they need to use the Homebrew Perl to install modules instead of the\nsystem Perl, then they should do that. It sounds like we're engineering\na feature that lets users shoot themselves in the foot to work around an\neasily fixable distributor issue.\n\nI'm sympathetic to the difficult job of distributors, but Git is not an\nunreasonable upstream, and I don't think it's unfair to ask Homebrew to\nsolve this problem in their distribution.\n\nI've commented on the issue on their GitHub repository, asking them to\naddress this problem.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"365903","messageId":"CAJdN7KgO4gGSkcDq1dOHZZYDj0qGnRq+AU4CF+UzHdJtNYGhng@mail.gmail.com","threadId":"50063","inReplyTo":"20181224022042.GE26554@genre.crustytoothpaste.net","subject":"Re: Can git choose perl at runtime?","fromName":"John Passaro","fromEmail":"john.a.passaro@gmail.com","sentAt":"2018-12-28T15:38:54Z","receivedAt":"2018-12-28T15:39:34Z","isPatch":false,"sender":{"key":"john.a.passaro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6754005?v=4"},"body":"On Sun, Dec 23, 2018 at 9:20 PM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> I think we should just ask Homebrew to ship a functional, complete Git.\n\nThey are doing just that:\nhttps://github.com/Homebrew/homebrew-core/pull/35446\nIf for some reason this patch doesn't make it in, I'll keep bugging\nthem about it, but this does seem like the preferable solution.\nThank you everybody for chiming in.\n"}]}