8 ms·

What is this post responding to? This: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d6e1c67755150653dff https://github.com/rails/rails/commit/61b

• javajosh 14y ago
  Thanks. I'm not really a rails person, so forgive me if I have some questions. Am I correct in interpreting that thread as DHH not wanting to support multiple ruby package managers in the rails codebase? In particular, DHH has 'blessed' rbenv and that commit wants to support rvm? If this is the case, then I have to wonder: why is there any dependency on a package manager at all in the rails codebase? This just seems odd to me, and perhaps is the source of the conflict. E.g. people are fine with 'omakase' frameworks, but these menus typically don't include toolchain dishes. It would be like going into a restaurant and being told that you must use chopsticks, no forks allowed.
  • steveklabnik 14y ago
    > In particular, DHH has 'blessed' rbenv and that commit wants to support rvm? No. Two things are going on: 1. 'binstubs' will now be checked into source control. If I use MRI and you use JRuby, they'll start with different things, and therefore, cause conflict. 2. Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now. David maintains that if I use MRI and you use JRuby, or if I use rvm and you use rbenv, this is an 'organizational failure.'
    • phene 14y ago
      Because no one ever wants to test their app against multiple versions of Ruby...
    • sstephenson 14y ago
      "Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now." Incorrect. It is support for an enhancement that rbenv provides. You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub. rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.
      • steveklabnik 14y ago
        Thank you for clarifying the exact circumstances, Sam. I don't use rbenv, I was going by discussions on the ticket and in Campfire. I was referring to that difference in the binstub, but maybe should have been more clear that that's a conflict with the enhancement and not the base features of rbenv.
    • mark_story 14y ago
      If a team is using different versions/runtimes of ruby I would have to agree this is an organizational feature in some cases. If you're working on a webapp you should be aiming to make as few differences between a development box & production as possible. Its unlikely that you have jruby & mri in production, wherein lies the failure.
      • steveklabnik 14y ago
        Square is one example of a company which famously develops in MRI but deploys JRuby to production.
        • mark_story 14y ago
          That sounds crazy to me, but I have very little experience with ruby. In PHP/python doing that can be unpleasant.
          • yb66 14y ago
            One big reason for this is the different start up times between versions of Ruby, especially JRuby vs anything else. It can impact your development time quite a lot. If you know they're compatible and you have specs there should be little problem with doing this. I completely disagree with DHH btw. Checking in generated files is a no no in my book, as is telling other people that using differing version managers is organisation failure, as is this kind of teenager's-diary style blog post. He needs to take a step back and breathe.
• davedx 14y ago
  And also the corresponding reaction on Twitter: https://twitter.com/jon_lemmon/status/284075141967790080 https://twitter.com/jon_lemmon/status/284075141967790080
  • killahpriest 14y ago
    @dhh: @jon_lemmon Why don’t you go ahead and fork rails so you can change the default gitignore file for new apps? You can call it Rails on Drama. ROFL, DHH has cajones.
    • killahpriest 14y ago
      Apparently somebody has bigger cajones. @sbartholomew: @dhh the the Rails community has it relatively easy: http://article.gmane.org/gmane.linux.kernel/1414106 http://article.gmane.org/gmane.linux.kernel/1414106 … :-)
      • amalag 14y ago
        Lol, imagine the flames if DHH had that kind of personality. People are being molly-coddled by DHH for stupid stuff like a default in .gitignore.
        • steveklabnik 14y ago
          This 'stupid stuff' breaks every single new Rails app on Heroku that uses rbenv.
          • erikpukinskis 14y ago
            Exactly zero of the Rails apps on Heroku will break. When you create a new app you'll need to remove a line from the autogenerated .gitignore in order to work the way you expect. No?
            • steveklabnik 14y ago