Rails Ruby on Rails → 3.0.2

Comments and changes to this ticket

• 

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

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

  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?

• You flagged this item as spam.
  

  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.

  Abraços.

• 

  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?

• You flagged this item as spam.
  

  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 February 26th, 2010 @ 12:40 PM

  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. :)

• You flagged this item as spam.
  

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

  sure thing. tomorrow.

• You flagged this item as spam.
  

  Caio Chassot February 26th, 2010 @ 09:03 PM

  Done.

  Pull | Diff

• 

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

  • State changed from “new” to “committed”
• 

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

  • State changed from “committed” to “open”

• You flagged this item as spam.
  

  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

  • 0001-use-basename-of-bundle_command.patch 898 Bytes

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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 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.

• You flagged this item as spam.
  

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

  I updated my branch with the fix you mention.

• You flagged this item as spam.
  

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

  Didn't touch the tests tho.

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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
  <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 "."
  

• 

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

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

• You flagged this item as spam.
  

  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.

  • 4029.patch 1.9 KB
• 

  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 March 5th, 2010 @ 04:46 PM

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

• You flagged this item as spam.
  

  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 March 12th, 2010 @ 08:36 PM

  • State changed from “open” to “committed”

  Applied.

• 

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

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

  [bulk edit]