This project is archived and is in readonly mode.

#4029 ✓committed
Caio Chassot

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

Reported by Caio Chassot | February 22nd, 2010 @ 07:28 AM | in 3.0.2

In app_generator, fix hardcoded bundle call to derive the bundle executable name from ruby_install_name.

This ensures that eg. when rails is called from ruby1.9, bundle1.9 is called.

Calling just bundle would use the ruby 1.8 bundle.

Pull | Diff | See also

Comments and changes to this ticket

  • José Valim

    José Valim February 23rd, 2010 @ 09:16 PM

    • Assigned user set to “José Valim”
    • Milestone cleared.
  • José Valim

    José Valim February 26th, 2010 @ 11:13 AM

    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?

  • Caio Chassot

    Caio Chassot February 26th, 2010 @ 12:15 PM

    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.


  • José Valim

    José Valim February 26th, 2010 @ 12:25 PM

    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?

  • Caio Chassot

    Caio Chassot February 26th, 2010 @ 12:30 PM

    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'
  • José Valim

    José Valim February 26th, 2010 @ 12:40 PM

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

    It does exactly what you want. :)

  • Caio Chassot
  • Caio Chassot
  • José Valim

    José Valim March 3rd, 2010 @ 09:14 AM

    • State changed from “new” to “committed”
  • José Valim

    José Valim March 4th, 2010 @ 04:31 PM

    • State changed from “committed” to “open”
  • Sakuro

    Sakuro March 5th, 2010 @ 02:47 AM

    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 also be closed :-p

  • Caio Chassot

    Caio Chassot March 5th, 2010 @ 03:47 AM

    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.

  • Sakuro

    Sakuro March 5th, 2010 @ 04:20 AM

    gem's wrapper is not always installed in the same directory of ruby itself.
    See #4100 for an example situation.

  • José Valim

    José Valim March 5th, 2010 @ 07:14 AM

    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.

  • Caio Chassot

    Caio Chassot March 5th, 2010 @ 07:22 AM

    I updated my branch with the fix you mention.

  • Caio Chassot

    Caio Chassot March 5th, 2010 @ 07:25 AM

    Didn't touch the tests tho.

  • Caio Chassot

    Caio Chassot March 5th, 2010 @ 07:58 AM

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

  • Sakuro

    Sakuro March 5th, 2010 @ 03:54 PM

    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
             run  bundle1.9 install from "."
    $ rvm use mput-head%rails3b
    $ ruby ~/Projects/rails/railties/bin/rails myapp_mput --dev
             run  bundle install from "."
  • José Valim

    José Valim March 5th, 2010 @ 04:14 PM

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

  • Caio Chassot

    Caio Chassot March 5th, 2010 @ 04:17 PM

    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.

  • José Valim

    José Valim March 5th, 2010 @ 04:24 PM

    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.

  • Jeremy Kemper

    Jeremy Kemper March 5th, 2010 @ 04:46 PM

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

  • Caio Chassot

    Caio Chassot March 5th, 2010 @ 04:50 PM

    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)

  • José Valim

    José Valim March 12th, 2010 @ 08:36 PM

    • State changed from “open” to “committed”


  • Jeremy Kemper

    Jeremy Kemper October 15th, 2010 @ 11:01 PM

    • Milestone set to 3.0.2
    • Importance changed from “” to “Low”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>


Referenced by