{"thread":{"id":"37750","subject":"Stop prepending /usr/bin to hooks PATH, or document it very clearly","startedAt":"2014-10-17T11:25:42Z","lastAt":"2014-10-18T16:45:51Z","messageCount":3,"participants":["Ciro Santilli","Andreas Krey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"250796","messageId":"CAFXrp_c+dxafLOO6T=LDd6OxhfpamkJsUc8iBwB-B41z8Htc4A@mail.gmail.com","threadId":"37750","inReplyTo":null,"subject":"Stop prepending /usr/bin to hooks PATH, or document it very clearly","fromName":"Ciro Santilli","fromEmail":"ciro.santilli@gmail.com","sentAt":"2014-10-17T11:25:42Z","receivedAt":"2014-10-17T11:25:42Z","isPatch":false,"sender":{"key":"ciro.santilli@gmail.com","avatar":"https://gravatar.com/avatar/24a59ac21bfa4133ba88106940ec03cc546a14b2afd61ff6b810b06b9732a772?d=mp&s=160"},"body":"On hooks Git automatically prepends to the `PATH` via the `setup_path` function:\n\n- `git --exec-path` (`/usr/lib/git-core`)\n- the directory of `$0` (`/usr/bin`) if you call it with the full path\n\nThe problem is that the `/usr/bin` breaks \"interpreter version manager\nsystems\" like RVM, rbenv, virtualenv, etc. since people will write\nhooks like:\n\n #!/usr/bin/env ruby\n\nand the `/usr/bin` ruby will get run instead of the managed one\n(`~/.rvm/some/path/bin).\n\nI recommend either:\n\n- not adding the `$0` if possible (ideal but backwards incompatible\nunless a new config is added)\n- documenting this behavior *very* clearly on `man githooks`\n- proposing some other mechanism that neatly solves the problem\n\nI will try to submit a patch for the desired solution if within my\ntechnical capability.\n\nSamples of problems this has caused people:\n\n- https://github.com/gitlabhq/gitlabhq/issues/8045\n- http://stackoverflow.com/questions/9037284/how-can-i-run-a-virtualenv-python-script-as-a-git-pre-commit-hook\n- http://stackoverflow.com/questions/17515769/why-is-my-ruby-git-script-hook-run-with-the-wrong-path\n- https://github.com/sstephenson/rbenv/issues/374\n- https://github.com/magit/magit/issues/498\n"},{"id":"250809","messageId":"20141018144924.GA17925@inner.h.apk.li","threadId":"37750","inReplyTo":"CAFXrp_c+dxafLOO6T=LDd6OxhfpamkJsUc8iBwB-B41z8Htc4A@mail.gmail.com","subject":"Re: Stop prepending /usr/bin to hooks PATH, or document it very clearly","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2014-10-18T14:49:24Z","receivedAt":"2014-10-18T14:49:24Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Fri, 17 Oct 2014 13:25:42 +0000, Ciro Santilli wrote:\n...\n> The problem is that the `/usr/bin` breaks \"interpreter version manager\n> systems\" like RVM, rbenv, virtualenv, etc. since people will write\n> hooks like:\n> \n> #!/usr/bin/env ruby\n> \n> and the `/usr/bin` ruby will get run instead of the managed one\n\nAnd that is the right thing to do. What ruby to execute with is\na property of the hook script, not of the virtualenv a user happens\nto be in. If you want virtualenvs, you should set up the right one\nwithin the hook script.\n\n...\n> - documenting this behavior *very* clearly on `man githooks`\n\nThat would still be a good thing to do.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"250810","messageId":"CAFXrp_fspAC1Q2NOzpFoxG=pQ1SsR3VaRf+BGx9V_dxUu7=diw@mail.gmail.com","threadId":"37750","inReplyTo":"20141018144924.GA17925@inner.h.apk.li","subject":"Re: Stop prepending /usr/bin to hooks PATH, or document it very clearly","fromName":"Ciro Santilli","fromEmail":"ciro.santilli@gmail.com","sentAt":"2014-10-18T16:45:51Z","receivedAt":"2014-10-18T16:45:51Z","isPatch":false,"sender":{"key":"ciro.santilli@gmail.com","avatar":"https://gravatar.com/avatar/24a59ac21bfa4133ba88106940ec03cc546a14b2afd61ff6b810b06b9732a772?d=mp&s=160"},"body":"On Sat, Oct 18, 2014 at 4:49 PM, Andreas Krey wrote:\n> On Fri, 17 Oct 2014 13:25:42 +0000, Ciro Santilli wrote:\n> ...\n>> The problem is that the `/usr/bin` breaks \"interpreter version manager\n>> systems\" like RVM, rbenv, virtualenv, etc. since people will write\n>> hooks like:\n>>\n>> #!/usr/bin/env ruby\n>>\n>> and the `/usr/bin` ruby will get run instead of the managed one\n>\n> And that is the right thing to do. What ruby to execute with is\n> a property of the hook script, not of the virtualenv a user happens\n> to be in. If you want virtualenvs, you should set up the right one\n> within the hook script.\n>\n\nI'm sure what you say has a good rationale, but can you give a more\nconcrete example where PATH prepending is desirable?\n\nUse cases that I have seen where it is surprising and undesirable:\n\n- I want binaries I manually installed under `/usr/local/bin` to have\nprecedence over the system defaults under `/usr/bin`, so I modify the\nPATH on my `.profile`. But then I run a hook and things fail: so in\neach hook I have to do export PATH=\"$THE_GOOD_PATH\", which makes me\nrepeat the same thing many times.\n\n- Locally I use RVM. But the CI uses rbenv. Next year, there will be\nanother version manager. If we follow the rule that when I invoke\n`system('git something')` it runs in the same environment as current,\nI don't need to do anything. But if environments change, I'd have to\neither write extra code for each manager, or install dependencies on\nmultiple versions of the interpreter.\n\nFor now I'm going to go with `export PATH=\"$THE_GOOD_PATH && ruby\nreal_script.rb\"`.\n\n> ...\n>> - documenting this behavior *very* clearly on `man githooks`\n>\n> That would still be a good thing to do.\n>\n> Andreas\n>\n> --\n> \"Totally trivial. Famous last words.\"\n> From: Linus Torvalds \n> Date: Fri, 22 Jan 2010 07:29:21 -0800\n"}]}