Skip to content
This repository was archived by the owner on Oct 19, 2023. It is now read-only.

can't get it to run the rvm ruby #5

Open
ericcj opened this issue Feb 14, 2013 · 5 comments
Open

can't get it to run the rvm ruby #5

ericcj opened this issue Feb 14, 2013 · 5 comments

Comments

@ericcj
Copy link
Contributor

ericcj commented Feb 14, 2013

despite having the rvm stuff in my bash_profile and bashrc i can't get this hook to use the rvm ruby when called with the shebang #!/usr/bin/env ruby. seems to work fine at the terminal, does git abandon all environment variables before running hooks?

beezo:~ ej$ /usr/bin/env ruby -v
ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-darwin12.2.1]

beezo:~ ej$ git --version
git version 1.7.12.4 (Apple Git-37)
hub version 1.10.4

@cypher
Copy link
Owner

cypher commented Feb 15, 2013

Looks like it prepends PATH with /usr/bin (/usr/libexec/git-core:/usr/bin to be exact), thus the system Ruby is the first one it finds.

I can think of two solutions right now: Either use the complete path to your version of Ruby as the shebang (e.g. /usr/local/rvm/bin/ruby-1.9.2-p290@projectX, see Using RVM with Cron for more details), or use a wrapper shell script that sources your RVM environment before execing the Ruby script.

@ericcj
Copy link
Contributor Author

ericcj commented Feb 15, 2013

using the path to the rvm ruby as the shebang isn't enough since below we do "which ruby". you can't actually use the wrapper scripts as shebangs either, they require being passed the ruby script as an argument. we also use "erb" without any path setup.

i can get everything to work by manually replacing that line with:

/Users/ej/.rvm/wrappers/default/erb -xT - views/admin/users/index.erb | /Users/ej/.rvm/wrappers/default/ruby -wc

but it'd be nice to generalize. i guess we could do some hackery around looking if there's a ${HOME}/.rvm/wrappers/default like we do with rbx. there's a confusing git issue about whether this is even supposed to be the case: magit/magit#498 (comment)

@ghost
Copy link

ghost commented Apr 7, 2013

I'm having the same issue with rbenv, anyone found a clean solution other than referencing a specific version? rbenv/rbenv#374 (comment)

@cypher
Copy link
Owner

cypher commented Apr 9, 2013

I think pretty much the only solution would be to restore the original $PATH by removing the first two entries. That way, rvm/rbenv should be used to get whatever Ruby you set.

However, a possible downside is that this may have unintended side effects, like some git porcelain suddenly not working any more. And it's brittle as hell, since Git may change this behavior in future.

I've just pushed 8c302a1, could you test with that commit and see if it works then? If it does, then maybe we can come up with a sane way to restore the original $PATH without possibly breaking everything.

@ghost
Copy link

ghost commented Apr 9, 2013

This doesn't work unfortunately as should the ruby file contain and syntax only available in a specific version (such as 1.9's hash syntax vs 1.8's traditional syntax) then by the time the path gets replaced, the error has already happened e.g.

#!/usr/bin/env ruby

if ENV['PATH'] =~ %r{\A/usr/libexec/git-core:/usr/bin:?(.*)\z}
  ENV['PATH'] = $1
end
puts "RUBY: #{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}, PATH: #{ENV['PATH'].inspect}, RBENV_VERSION: #{ENV['RBENV_VERSION']}"

something = { foo: 'bar' }

...in this case, if the system version is 1.8 and the rbenv version is 1.9, there will still be a parse error before the new path can take effect.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants