{"thread":{"id":"38256","subject":"Git's Perl scripts can fail if user is configured for perlbrew","startedAt":"2014-12-28T22:36:01Z","lastAt":"2015-01-02T03:08:25Z","messageCount":8,"participants":["Randy J. Ray","Ævar Arnfjörð Bjarmason","Torsten Bögershausen","Kang-min Liu","Ben Aveling"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"254131","messageId":"54A085D1.8060407@blackperl.com","threadId":"38256","inReplyTo":null,"subject":"Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Randy J. Ray","fromEmail":"rjray@blackperl.com","sentAt":"2014-12-28T22:36:01Z","receivedAt":"2014-12-28T22:36:01Z","isPatch":false,"sender":{"key":"rjray@blackperl.com","avatar":"https://gravatar.com/avatar/9b8d45ea6c2884ade123747610827c57767acfdd8e076b526035d9f454fbee44?d=mp&s=160"},"body":"I use git on MacOS via homebrew (http://brew.sh/), and a custom Perl \ninstallation built and managed via perlbrew (http://perlbrew.pl/). At \nsome point, commands like \"git add -i\" broke. I say \"at some point\", \nbecause I'm not a git power-user and I only just noticed it this week.\n\nI am running Git 2.2.1 with a perlbrew'd Perl 5.20.1. When I would run \n\"git add -i\" (or \"git add -p\"), it would immediately die with a signal \n11. Some poking around showed that those git commands that are \nimplemented as Perl scripts run under /usr/bin/perl, and also prefix \nsome directories to the module search-path. The problem stems from the \nfact that, when you are using perlbrew, you also have the PERL5LIB \nenvironment variable set. The contents of it lay between the \ngit-provided paths and the default contents of @INC. When the Git module \nis loaded, it (eventually) triggers a load of List::Util, whose C-level \ncode fails to load because of a version mismatch; you got List::Util \nfrom the paths in PERL5LIB, but it doesn't match the version of perl \nfrom /usr/bin/perl.\n\nAfter poking around and trying a few different things, I have found that \nusing the following line in place of \"#!/usr/bin/perl\" solves this problem:\n\n\t#!/usr/bin/env perl\n\nThis can be done by defaulting PERL_PATH to \"/usr/bin/env perl\" in Makefile.\n\nI don't know enough about the overall git ecosystem to know if this \nwould have an adverse effect on anything else (in particular, Windows \ncompatibility, but then Windows probably isn't having this issue in the \nfirst place).\n\nI could just create and mail in the one-line patch for this, but I \nthought it might be better to open it up for some discussion first?\n\nRandy\n-- \n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\nRandy J. Ray      Sunnyvale, CA      http://www.dereferenced.com\nrjray@blackperl.com\ntwitter.com/rjray\nSilicon Valley Scale Modelers: http://www.svsm.org\n"},{"id":"254135","messageId":"CACBZZX4qKyfRcbowYnM-KsrbKZ2=9RXr+HEgrOU1jaCsSX53QA@mail.gmail.com","threadId":"38256","inReplyTo":"54A085D1.8060407@blackperl.com","subject":"Re: Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2014-12-29T13:21:57Z","receivedAt":"2014-12-29T13:21:57Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Dec 28, 2014 at 11:36 PM, Randy J. Ray <rjray@blackperl.com> wrote:\n> I use git on MacOS via homebrew (http://brew.sh/), and a custom Perl\n> installation built and managed via perlbrew (http://perlbrew.pl/). At some\n> point, commands like \"git add -i\" broke. I say \"at some point\", because I'm\n> not a git power-user and I only just noticed it this week.\n>\n> I am running Git 2.2.1 with a perlbrew'd Perl 5.20.1. When I would run \"git\n> add -i\" (or \"git add -p\"), it would immediately die with a signal 11. Some\n> poking around showed that those git commands that are implemented as Perl\n> scripts run under /usr/bin/perl, and also prefix some directories to the\n> module search-path. The problem stems from the fact that, when you are using\n> perlbrew, you also have the PERL5LIB environment variable set. The contents\n> of it lay between the git-provided paths and the default contents of @INC.\n> When the Git module is loaded, it (eventually) triggers a load of\n> List::Util, whose C-level code fails to load because of a version mismatch;\n> you got List::Util from the paths in PERL5LIB, but it doesn't match the\n> version of perl from /usr/bin/perl.\n>\n> After poking around and trying a few different things, I have found that\n> using the following line in place of \"#!/usr/bin/perl\" solves this problem:\n>\n>         #!/usr/bin/env perl\n>\n> This can be done by defaulting PERL_PATH to \"/usr/bin/env perl\" in Makefile.\n>\n> I don't know enough about the overall git ecosystem to know if this would\n> have an adverse effect on anything else (in particular, Windows\n> compatibility, but then Windows probably isn't having this issue in the\n> first place).\n>\n> I could just create and mail in the one-line patch for this, but I thought\n> it might be better to open it up for some discussion first?\n\n[CC'd the perlbrew author]\n\nThis is a bit of a tricky issue.\n\nUsing whatever perl is defined in the environment is just as likely to\nbreak, in general the build process tries to pick these assets at\ncompile-time. Imagine you're experimenting with some custom perl\nversion and now Git inexplicably breaks.\n\nIt's better if Git detects a working perl when you compile it and\nsticks with that, which is why we use /usr/bin/perl by default.\n\nWhen you're setting PERL5LIB you're indicating to whatever perl\ninterpreter you're going to run that that's where they it should pick\nup its modules. IMO they way perlbrew does this is broken, instead of\nsetting PATH + PERL5LIB globally for your login shell it should set\nthe PATH, and then the \"perl\" in that path should be a pointer to some\nsmall shellscript that sets PERL5LIB for *its* perl.\n\nI don't know what the right tradeoff here is, but I think it would be\njust as sensible to unset PERL5LIB in our own perl scripts + modules,\nit would make live monkeypatching when you wanted to harder, but we\ncould always add a GITPERL5LIB or something...\n"},{"id":"254136","messageId":"54A159D7.5010307@web.de","threadId":"38256","inReplyTo":"54A085D1.8060407@blackperl.com","subject":"Re: Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-12-29T13:40:39Z","receivedAt":"2014-12-29T13:40:39Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2014-12-28 23.36, Randy J. Ray wrote:\n> I use git on MacOS via homebrew (http://brew.sh/), and a custom Perl installation built and managed via perlbrew (http://perlbrew.pl/). At some point, commands like \"git add -i\" broke. I say \"at some point\", because I'm not a git power-user and I only just noticed it this week.\n> \n> I am running Git 2.2.1 with a perlbrew'd Perl 5.20.1. When I would run \"git add -i\" (or \"git add -p\"), it would immediately die with a signal 11. Some poking around showed that those git commands that are implemented as Perl scripts run under /usr/bin/perl, and also prefix some directories to the module search-path. The problem stems from the fact that, when you are using perlbrew, you also have the PERL5LIB environment variable set. The contents of it lay between the git-provided paths and the default contents of @INC. When the Git module is loaded, it (eventually) triggers a load of List::Util, whose C-level code fails to load because of a version mismatch; you got List::Util from the paths in PERL5LIB, but it doesn't match the version of perl from /usr/bin/perl.\n> \n> After poking around and trying a few different things, I have found that using the following line in place of \"#!/usr/bin/perl\" solves this problem:\n> \n>     #!/usr/bin/env perl\n> \n> This can be done by defaulting PERL_PATH to \"/usr/bin/env perl\" in Makefile.\n> \n> I don't know enough about the overall git ecosystem to know if this would have an adverse effect on anything else (in particular, Windows compatibility, but then Windows probably isn't having this issue in the first place).\n> \n> I could just create and mail in the one-line patch for this, but I thought it might be better to open it up for some discussion first?\n> \n> Randy\n\nHaving problems with different perl installations is not an unknown problem\nin Git, I would say.\n\nAnd Git itself is prepared to handle this situation:\n\nIn Makefile I can read:\n# Define PERL_PATH to the path of your Perl binary (usually /usr/bin/perl).\n\n(What Git can not decide is which perl it should use, the one pointed out by $PATH or /usr/bin/perl.)\n\nWhat does  \n\"type perl\" say ?\n\nAnd what happens when you build and install Git like this:\nPERL_PATH=/XX/YY/perl make install\n\n-----------\nAre you thinking about changing\nifndef PERL_PATH\n\tPERL_PATH = /usr/bin/perl\nendif\n-- into --\nifndef PERL_PATH\n\tPERL_PATH = $(shell which perl)\nendif\n---\n\nAt first glance that could make sense, at least to me.\n"},{"id":"254152","messageId":"54A1C29C.4090100@blackperl.com","threadId":"38256","inReplyTo":"CACBZZX4qKyfRcbowYnM-KsrbKZ2=9RXr+HEgrOU1jaCsSX53QA@mail.gmail.com","subject":"Re: Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Randy J. Ray","fromEmail":"rjray@blackperl.com","sentAt":"2014-12-29T21:07:40Z","receivedAt":"2014-12-29T21:07:40Z","isPatch":false,"sender":{"key":"rjray@blackperl.com","avatar":"https://gravatar.com/avatar/9b8d45ea6c2884ade123747610827c57767acfdd8e076b526035d9f454fbee44?d=mp&s=160"},"body":"On 12/29/14, 7:21 AM, Ævar Arnfjörð Bjarmason wrote:\n> [CC'd the perlbrew author]\n>\n> This is a bit of a tricky issue.\n>\n> Using whatever perl is defined in the environment is just as likely to\n> break, in general the build process tries to pick these assets at\n> compile-time. Imagine you're experimenting with some custom perl\n> version and now Git inexplicably breaks.\n>\n> It's better if Git detects a working perl when you compile it and\n> sticks with that, which is why we use /usr/bin/perl by default.\n\nThese are good points. I'm not sure when this stopped working for me... \nI don't use the -i or -p options to \"git add\" very often. So I can't say \nat what point it stopped working with the current configuration, only \nthat it \"used to work\".\n\n> When you're setting PERL5LIB you're indicating to whatever perl\n> interpreter you're going to run that that's where they it should pick\n> up its modules. IMO they way perlbrew does this is broken, instead of\n> setting PATH + PERL5LIB globally for your login shell it should set\n> the PATH, and then the \"perl\" in that path should be a pointer to some\n> small shellscript that sets PERL5LIB for *its* perl.\n\nThat would be for the perlbrew author to consider, of course.\n\n> I don't know what the right tradeoff here is, but I think it would be\n> just as sensible to unset PERL5LIB in our own perl scripts + modules,\n> it would make live monkeypatching when you wanted to harder, but we\n> could always add a GITPERL5LIB or something...\n\nYou would have to have a shell script that un-set PERL5LIB and then \ninvoked the given git script, because by the time script execution has \nbegun, the contents of PERL5LIB have already been added to the head of \nthe list of search paths. One approach I tried was to set the \nenvironment variable GITPERLLIB (which you already use and recognize, so \nthere is no need for GITPERL5LIB), but that did not help. The base \nproblem still remained: The content of PERL5LIB (which pointed to \n5.20.1-compiled extensions) took priority over the default @INC contents \n(which were for a 5.16.2 perl).\n\nI don't know the right trade-off, either. I started out reporting this \nas an issue against the homebrew project's recipe for git, because they \nactually add more explicit library paths to @INC than a vanilla \nbuild/install of git does. But the problem is really in the interaction \nbetween /usr/bin/perl and a PERL5LIB set for an alternate perl. So the \nsolution, if there is one, will lay here in git somewhere...\n\nRandy\n-- \n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\nRandy J. Ray      Sunnyvale, CA      http://www.dereferenced.com\nrjray@blackperl.com\ntwitter.com/rjray\nSilicon Valley Scale Modelers: http://www.svsm.org\n"},{"id":"254166","messageId":"54A1CE4A.7020408@blackperl.com","threadId":"38256","inReplyTo":"54A159D7.5010307@web.de","subject":"Re: Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Randy J. Ray","fromEmail":"rjray@blackperl.com","sentAt":"2014-12-29T21:57:30Z","receivedAt":"2014-12-29T21:57:30Z","isPatch":false,"sender":{"key":"rjray@blackperl.com","avatar":"https://gravatar.com/avatar/9b8d45ea6c2884ade123747610827c57767acfdd8e076b526035d9f454fbee44?d=mp&s=160"},"body":"On 12/29/14, 7:40 AM, Torsten Bögershausen wrote:\n> Having problems with different perl installations is not an unknown problem\n> in Git, I would say.\n>\n> And Git itself is prepared to handle this situation:\n>\n> In Makefile I can read:\n> # Define PERL_PATH to the path of your Perl binary (usually /usr/bin/perl).\n>\n> (What Git can not decide is which perl it should use, the one pointed out by $PATH or /usr/bin/perl.)\n>\n> What does\n> \"type perl\" say ?\n>\n> And what happens when you build and install Git like this:\n> PERL_PATH=/XX/YY/perl make install\n>\n> -----------\n> Are you thinking about changing\n> ifndef PERL_PATH\n> \tPERL_PATH = /usr/bin/perl\n> endif\n> -- into --\n> ifndef PERL_PATH\n> \tPERL_PATH = $(shell which perl)\n> endif\n> ---\n>\n> At first glance that could make sense, at least to me.\n\nThe problem in this case is the Perl being used at run-time, not \nbuild-time. The building of git is done by the homebrew project in this \ncase, so I don't have direct control over it.\n\nRandy\n-- \n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\nRandy J. Ray      Sunnyvale, CA      http://www.dereferenced.com\nrjray@blackperl.com\ntwitter.com/rjray\nSilicon Valley Scale Modelers: http://www.svsm.org\n"},{"id":"254170","messageId":"m2iogujbon.fsf@gugod.org","threadId":"38256","inReplyTo":"54A1C29C.4090100@blackperl.com","subject":"Re: Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Kang-min Liu","fromEmail":"gugod@gugod.org","sentAt":"2014-12-29T23:09:12Z","receivedAt":"2014-12-29T23:09:12Z","isPatch":false,"sender":{"key":"gugod@gugod.org","avatar":null},"body":"\n\n> On 12/29/14, 7:21 AM, Ævar Arnfjörð Bjarmason wrote:\n>> [CC'd the perlbrew author]\n>>\n>> This is a bit of a tricky issue.\n>>\n>> Using whatever perl is defined in the environment is just as likely to\n>> break, in general the build process tries to pick these assets at\n>> compile-time. Imagine you're experimenting with some custom perl\n>> version and now Git inexplicably breaks.\n>>\n>> It's better if Git detects a working perl when you compile it and\n>> sticks with that, which is why we use /usr/bin/perl by default.\n\nWith \"perl\" being an external dependency, sticking with whatever at the\ncompile time basically means these should stick:\n\n- `which perl`, and the same $Config options\n- Every module contained in PERL5LIB\n- Other external executable dependencies of some .pm files that lives\n  somewhere in PATH\n\nWe could of course build an app bundle dir like a lightweight container.\nto mitigate this... but that would'nt be usefull without tweaking the\nshebang line of the scripts -- to point to the perl script (shim or\nreal) that should be compatible with the newly built git.\n\nI'd argue that trying to compile git (or other stuff in general) against\na perlbrew-managed perl is something that \"perlbrew\" executable cannot\nmanage. Because it is both valid that the user is doing this\nintentionally and want the outcome, or the user is doing this\nunintentionally. And even if we have a shim \"perl\" script, it would'nt\nhelp as long as it is the \"whatever perl\" in PATH -- which might just be\nincompitble.\n\nI wonder if disabling perlbrew per-building can deal with this:\n\n    'perlbrew off'\n\nIf this end up changing the shebang line then maybe, if not then it'll\nstill intefere after perlbrew is re-activated.\n\nThe other option to minimize perlbrew interferince is of course to\ncompletely deprecate the global env var approach and make them project\nlocal. But that's another story.\n\n-- \nCheers,\nKang-min Liu\n"},{"id":"254171","messageId":"CACBZZX4PDC45jE6y1i-SFY5Qy+CPsBe-OMjfehZRYdqD9pWPaA@mail.gmail.com","threadId":"38256","inReplyTo":"54A1CE4A.7020408@blackperl.com","subject":"Re: Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2014-12-29T23:16:34Z","receivedAt":"2014-12-29T23:16:34Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Dec 29, 2014 at 10:57 PM, Randy J. Ray <rjray@blackperl.com> wrote:\n> On 12/29/14, 7:40 AM, Torsten Bögershausen wrote:\n>>\n>> Having problems with different perl installations is not an unknown\n>> problem\n>> in Git, I would say.\n>>\n>> And Git itself is prepared to handle this situation:\n>>\n>> In Makefile I can read:\n>> # Define PERL_PATH to the path of your Perl binary (usually\n>> /usr/bin/perl).\n>>\n>> (What Git can not decide is which perl it should use, the one pointed out\n>> by $PATH or /usr/bin/perl.)\n>>\n>> What does\n>> \"type perl\" say ?\n>>\n>> And what happens when you build and install Git like this:\n>> PERL_PATH=/XX/YY/perl make install\n>>\n>> -----------\n>> Are you thinking about changing\n>> ifndef PERL_PATH\n>>         PERL_PATH = /usr/bin/perl\n>> endif\n>> -- into --\n>> ifndef PERL_PATH\n>>         PERL_PATH = $(shell which perl)\n>> endif\n>> ---\n>>\n>> At first glance that could make sense, at least to me.\n>\n>\n> The problem in this case is the Perl being used at run-time, not build-time.\n> The building of git is done by the homebrew project in this case, so I don't\n> have direct control over it.\n\nCorrect, but we don't change /usr/bin/perl at runtime, we hardcode\nthat at compile-time.\n\nSimilarly we could hardcode PERL5LIB at compile-time, but we don't, if\nwe did you wouldn't have this problem.\n\nI.e. the problem is that we're using the system-provided perl with a\ncustom PERL5LIB set for the benefit of a non-system provided perl\ninstalled after you built Git (or built in a different environment...)\n"},{"id":"254247","messageId":"54A60BA9.1020204@optusnet.com.au","threadId":"38256","inReplyTo":"54A085D1.8060407@blackperl.com","subject":"Re: Git's Perl scripts can fail if user is configured for perlbrew","fromName":"Ben Aveling","fromEmail":"bena.001@optusnet.com.au","sentAt":"2015-01-02T03:08:25Z","receivedAt":"2015-01-02T03:08:25Z","isPatch":false,"sender":{"key":"bena.001@optusnet.com.au","avatar":null},"body":"On 29/12/14 09:36, Randy J. Ray wrote:\n> I don't know enough about the overall git ecosystem to know if this \n> would have an adverse effect on anything else (in particular, Windows \n> compatibility, but then Windows probably isn't having this issue in \n> the first place).\n\nPerlbrew doesn't support Windows, so no, not an issue for Windows.\n\nRegards, Ben\n"}]}