`ruby1.9 rails/railties/bin/rails foo --dev` will eventually call `bundle`, it should call `bundle1.9`

Thanks for the patch, but it still has some issues. For instance, on jruby, it would try to call jbundle and I don't think it will work. Or am I missing something here?

I have no idea about jruby, but pragmatically speaking, either people have one single ruby installation and it's called 'ruby', or they have both, eg. via macports or the freebsd equivalents or whatever people have in linux these days.

ultimately, i think it's much more probable that a ruby developer will have two distinct ruby installs for 1.8 and 1.9 (and macruby if you're a mac dev.), than they'll have jruby or ironwhatever.

if you're playing with more than 1.8 and 1.9, I'm taking into account that you know your shit, and you're able to work around the weirdnesses of your setup. certainly when you're dealing with non-mri ruby, like macruby, rubinius, jruby.

one could make this work with all of them in every occasion, and I actually did dig into that with @ped from heroku, but we found that it's just not worth the effort. Eg. you'd need facets to use which which also works on windows and a lot of other support libraries.

well, I don't have to tell you that heroku themselves are having quite a deal of issues with bundler. But I digress.

Here's my stance on it. It's better than what's currently in place.

Abraços.

I use rvm, so I don't have such issues. The best we can do then is allow you to pass the bundler command as option:

rails foo --dev --bundler=bundler1.9

Do you want to try a patch?

Deriving the bin name from ruby_install_name is kinda standard. That's what rubygems will do. If you use a mac and ruby1.9 via macports, when you install gems via gem1.9, you get bins like rake1.9. same for macruby, you get macrake.

So it's quite expectable.

At the very worst, what'll happen is that the sub will fail and you'll end up with the name you originally intended anyway. Well, as long as ruby is still in the string. But you can make it more exact by doing:

bin = ruby_install_name.dup.sub!('ruby', 'foo') || 'foo'

Ok, agreed. Could you please provide a new patch then but using Thor::Util.ruby_command this time?

http://github.com/wycats/thor/blob/master/lib/thor/util.rb#L218

It does exactly what you want. :)

sure thing. tomorrow.

Done.

Pull | Diff

Thor's ruby_command returns absolute path and breaks tests which expect "bundle install" to be executed.
This patch extracts basename from derived bundle command path.
Hoping #4100 commit 6f4c451 malfunctions with rvm's gemset also be closed :-p

I noticed that when I implemented it but I figured using the full path is actually the safer choice.

eg. Mac OS X ships with ruby in /usr/bin, but if you install ruby18 via macports you also end up with ruby in /opt/local/bin, and now which bundle gets called is totally dependent on your PATH.

I'd instead fix the tests.

gem's wrapper is not always installed in the same directory of ruby itself.
See #4100 commit 6f4c451 malfunctions with rvm's gemset for an example situation.

Sakuro, you could get the basename and just after it apply the regular expression (it works in the current way, is just that the regexp then could be simpler). Anyway, you should also fix the tests, becase now they will fail if you run then in ruby 1.9.

I updated my branch with the fix you mention.

Didn't touch the tests tho.

Pushed updated tests on my branch. Not sure if it's the best way to go about it, tho. Let me know.

I have tried Caio's bundle-bin-thor branch with following two environment and both worked.

A) MacPorts' ruby19
ruby executable path: /opt/local/bin/ruby1.9
bundle executable path: /opt/local/bin/bundle1.9
PATH: /usr/local/bin (There is only "mate", a symbolic link to TextMate)
/opt/local/bin (ruby1.9 gem1.9 and bundle1.9 are here) /Developer/Tools /usr/bin /bin /usr/sbin /sbin

B) mput-head installed using rvm with rails3b gemset
ruby executable path: $HOME/.rvm/rubies/mput-head/bin/ruby
bundle executable path: $HOME/.rvm/gems/mput-head%rails3b/bin/bundle
PATH: $HOME/.rvm/rubies/mput-head/bin (ruby is here)
$HOME/.rvm/gems/mputhead%rails3b/bin (bundle is here) $HOME/.rvm/gems/mput-head%global/bin $HOME/.rvm/bin $HOME/bin /usr/local/bin ...(same as above)

$ ruby1.9 ~/Projects/rails/railties/bin/rails myapp19 --dev
<snip>
         run  bundle1.9 install from "."

$ rvm use mput-head%rails3b
$ ruby ~/Projects/rails/railties/bin/rails myapp_mput --dev
<snip>
         run  bundle install from "."

Awesome. Caio, can you provide a patch with all commits in just one file? Thanks.

I will not dwell on the irony of the command to generate the patch being shorter than your request.

Here's the file. Bring your own commit message, tho.

The contributing guide asks specifically to provide a patch. git am patch -s is easier than adding a remote repository, checking if there isn't anything extra in the remote repository and then squashing commits.

If you apply ten patches in a row, as I usually do, you will know the difference.

Anyway, thanks for the patch.

Plus, using git format-patch preserves your authorship and commit history so nicely :)

Oh believe me I do. OTOH if you contribute patches to a bunch of different projects each with their own idiosyncrasies, you'll see that it takes its toll on the contributor too.

Github goes halfway in helping apply patches from elsewhere but for a project with ~800 forks like rails it's probably unworkable.

Anyway, I think it's a place where tools could help more, on both sides.

(Just imagine… rake submit-patch --squash master..HEAD 4029)