What is this post responding to?
This: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...
This: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...
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.
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.'
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.
ROFL, DHH has cajones.
@sbartholomew: @dhh the the Rails community has it relatively easy: http://article.gmane.org/gmane.linux.kernel/1414106 … :-)
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?
So Linus must be doing something right.
Linus was right, though.
And DHH was wrong.
Not a fan of the way Linus handled that, though he sure did set the tone and expectations for everyone else!
i'm betting he made that mail public very deliberately, as a way of telling the world at large that as kernel dictator he would not tolerate his "staff" treating users like that.
I think a big reason it's on the public list is because it should be. Linux is Linus' baby, he has every right to yell at someone for doing pretty much anything. And in this case, it was deserved. If you're going to break the first commandment of Linux development (don't break userspace), and blame the userspace for breaking, you should be reprimanded.
But that would be way overkilled, here, because we just speak of adding a line to the .gitignore file.
If you don't know git, .gitignore is a file you're expected to edit, you put there anything you don't want to commit in the repository.
So, once again, all the trolling is about changing a default option. Which can be changed back with one line of four characters ("/bin"), in a configuration file. Change to be made only once in the whole life of your application.