Commit
…s, we want you to check those in! This reverts commit 35c554f.
- Loading branch information
There are no files selected for viewing
71 comments
on commit 61b91c4
There was a problem hiding this comment.
I'm wondering what @dhh meant by "it doesn't work with rbenv", and why is 7173c4f considered necessary. /cc @wycats
A binstub generated with #!/usr/bin/env ruby will work just fine with rbenv, since it will hit the ruby shim and the right ruby version will be picked for the current environment/directory.
As long as executables in ./bin are called from inside the project's directory, rbenv will purr just fine. I see no need for Rails to be aware of rbenv (tools coupling with rbenv goes against rbenv's philosophy).
If you call ./bin executables from outside the directory, yes, then you want ruby-local-exec in your shebang. But since this is advanced usage that makes most sense for deploys, I don't think we need to be terribly concerned about it.
There was a problem hiding this comment.
David, thanks for the response. I mean just that. Some people might have things that conflict.
We don't enforce a specific ruby manager here and explicitly chose not to use one since we provide a single vendored ruby for you to use that's required by the application.
We've been using binstubs since Rails 3.1.x or at least supported that path. People of course always welcome to use bundle exec. The workaround you're suggesting is to go through every file in bin/ and search for any bundler binstub or more constrained rbenev binstub and delete them? We can't blindly delete bin/ since it can contain non ruby/bundler/rails related binaries.
There's another caveat that users who have forked the ruby buildpack and when using it against rails 4, it might break their app and won't know why.
There was a problem hiding this comment.
If Rails depends on bundler then I think it's reasonable to follow its patterns, and if that means checking in the binstubs then I guess that's what should happen. I just don't think Rails should depend on bundler (or any other platform management tool); of course I think Rails should try to load bundler if it wants and use it if it is there.
I hope this doesn't come across as a derailment; if it does I apologize for my inability to express it clearly enough.
My personal ideal of ruby library design allows for the possibility that it will be loaded from site_ruby, without even rubygems; I would, myself, not depend on bundler (or a non-standard shebang) in anything other than a rubygems/bundler plugin or similar.
There was a problem hiding this comment.
@wilson Bundler's official position is that people should NOT check in binstubs, as they are not necessarily portable.
Checking in binstubs is a decision that @dhh made because of his strongly held opinion that projects should have a single development environment shared by all developers. Bundler does not take that position.
There was a problem hiding this comment.
if you are unable to use the same Ruby manager in production and development, I feel bad for you.
I work on MRI with RVM locally then deploy some apps to Heroku on JRuby, some apps get wrapped in Warfiles and deployed onto Tomcat, other apps run against native Rubies running on Centos, others on Ubuntu.
Will these changes break my Rails apps deployed to heterogenous environments?
There was a problem hiding this comment.
From what @wycats have said, I think that support the case that we should not check in binstubs. I still wish that this got reverted until we can find a better solution to tell Bundler to recompile the binstubs when you run bundle install.
There was a problem hiding this comment.
There was a problem hiding this comment.
This really isn't a discussion about portability or development environments, despite those being good discussions. This should be a discussion about how Rails handles creating new applications. Shared environment or not, things that can be generated on the fly (assets, environment config files, binaries) generally shouldn't be checked into the repository. The generation process should (often does) handle platform specific details.
Since we're talking about a default .gitignore a new developer of a rails application should not be allowed to accidentally fill the repository with auto-generated junk. It should be opt-in due to the nature of git, as you're then saying: I want to handle, myself, what changes to this file goes into the repository. Most newbies don't want to handle that.
There was a problem hiding this comment.
@wycats thanks. :)
There was a problem hiding this comment.
quoting @wycats
Checking in binstubs is a decision that @dhh made because of his strongly held opinion that projects should have a single development environment shared by all developers. Bundler does not take that position.
This seems less like convention over configuration and more like convention over common sense. Maybe that was a bit trolltastic, but choosing what to normalize and what to leave optional is a design decision, and involves tradeoffs. I think this expectation, about how people organize their development environments, goes much too far.
quoting @krainboltgreene
This really isn't a discussion about portability or development environments, despite those being good discussions. This should be a discussion about how Rails handles creating new applications. Shared environment or not, things that can be generated on the fly (assets, environment config files, binaries) generally shouldn't be checked into the repository. The generation process should (often does) handle platform specific details.
I think this is a much wiser operating principle.
There was a problem hiding this comment.
@dhh If we change bundler to automatically generate binstubs when you bundle install, can we revert this commit? The binstubs will be always there, it will be portable and everyone is happy.
There was a problem hiding this comment.
Talking with @hone I suggested something like BUNDLE_BIN but outside of .bundle/config (since in this file we can have platform specific configs), in this way will be possible get the binstubs just cloning a repo and running 'bundle install'. wdyt?
There was a problem hiding this comment.
Just wanted to reiterate what @mislav said above—Bundler binstubs with #!/usr/bin/env ruby shebangs work fine with rbenv. The ruby-local-exec shebang is an enhancement that enables you to directly invoke binstubs (from, say, a cron job) without changing to the application directory first.
There was a problem hiding this comment.
@sstephenson so is it safe to remove the rbenv-specific code from Rails?
There was a problem hiding this comment.
Where is the rbenv-specific code in Rails?
There was a problem hiding this comment.
There was a problem hiding this comment.
Yes, strictly speaking it is safe to remove it. Whether or not it's the right thing to do is another matter.
There was a problem hiding this comment.
There was a problem hiding this comment.
Regardless, this optimization is only triggered for rbenv users. If you are unable to ensure that you can use the same Ruby manager in all envs, just gitignore bin.
There was a problem hiding this comment.
The way i do it is like this:
/bin is in version control. Manually add the bins that someone checking out the repo and the production env would need like "rake", "bundle", "unicorn", etc.
Add another directory inside bin: /bin/stubs
and add this directory to gitignore!
Change the line in .bundle/config to:
BUNDLE_BIN: bin/stubs
And be happy :-)
I think this is how 37s handles this aswell (not sure). But i think it's great!! :)
There was a problem hiding this comment.
@habermann24 Why would I want "rake" and "bundle" and "unicorn" from your repository when bundler will bring them in? At that point you might as well throw away your stubs folder and just throw it all into bin and ignore the entire thing. My point is, bin/ should be used for your application specific files... not files and bin/ files from your dependencies.
There was a problem hiding this comment.
I suggest that 'script/' is a natural place for binstubs, yet from 2.3 rails. And the 'bin/' is a great place to for application-related-bins (bin_script gem). In our project we have hundreds application-bins and don't want mix them with bundler binstubs in bin/.
There was a problem hiding this comment.
I use binstubs when I use RVM, but I wouldn't want to force other devs on my team to do the same.
Also, I'd like to not have bin/ diffs in my commits. Let bundler take care of that.
There was a problem hiding this comment.
Bundler generates binstubs automatically on bundle install. So what is an advantage of having them checked in?
There was a problem hiding this comment.
@semaperepelitsa you get to make shit hard, and troll people in the process.
There was a problem hiding this comment.
@semaperepelitsa just to make sure that you got it right, but currently bundler will only install and regenerate binstubs only if you ran bundle install --binstubs the first time. I'm trying to coordinate with @hone and @josevalim to make sure that we can somehow share the 'regenerate binstubs everytime you run bundle install' setting across the board, since I think that approach is better than checking in ./bin directory, and we don't have to unignore .bundle/.
There was a problem hiding this comment.
@josevalim @sikachu Auto-generating binstubs isn't fun if you're using multiple rubies for the same project. E.g., trying to make sure it works in both MRI and JRuby.
There was a problem hiding this comment.
@nirvdrum it should be fine for you if you're talking about the same machine, since your ruby version manager would manage to make sure that env ruby in the shebang works and point to the right version of Ruby. You would be able to run those binstubs without having to regenerate the ./bin
But the thing is, env ruby is not universal. On some platform, you might require a different shebang line to make those files work. In this case, regenerate the bin every time you run bundle install and .gitignore .bundle/ would be the best solution here, since the first thing you normally do after you clone down the project would be running bundle install anyway. ;)
There was a problem hiding this comment.
There are rails projects that are worked on by groups of people not all working for some company, other orgs where people work from home. Tons of situations and use cases in which forcing everyone to choose rbenv or rvm isn't feasible or even advisable.
There was a problem hiding this comment.
@sikachu JRuby doesn't ship with a ruby, so the shebang line is different. Using rbenv, it looks like #!/usr/bin/env jruby. Naturally, that won't work for MRI.
There was a problem hiding this comment.
I'm sad that on Twitter, DHH is trying to dismiss our feedback regarding this change as "nerdrage" about a "single line of code". What I'm seeing in this thread is a civilized debate with many smart people—some of which are high-profile members of our community—raising valid concerns backed up by arguments.
Let's recap. There are two related changes being discussed here:
- The
./bindirectory is no longer gitignored, signalling that people should check Bundler-generated binstubs in version control; - Rails now detects and special-cases rbenv, resulting in coupling between an application and a ruby version manager.
Even if the changes to Rails are technically small, the repercussions of these changes are not to be dismissed. Rails defaults are important because they teach us how Rails expects the majority of us to use it.
- Versioned binstubs are potentially non-portable (especially when coupled to rbenv), and it makes no sense having them under version control since every user needs to run
bundleanyway & can choose to get the binstubs (especially with the potential improvement that @sikachu mentioned). - rbenv detection is flawed (just detects rbenv being present on the system, not actually used) and introduces a coupling that both requires that everyone on the team and the deployment environment should use the same version manager, and results in binstubs breaking after a switch to another ruby version manager.
Also, during this discussion we've received input from notable figures:
- The author of Bundler expressed his disapproval of Bundler-generated binstubs getting version-controlled;
- The author of rbenv said that the coupling with rbenv is not necessary;
- An employee of Heroku is concerned about people's apps not functioning anymore on their platform;
- At least 3 Rails Core team members are participating, not happy with the change and proposing alternatives.
But somehow, DHH is still dismissing their opinions and ridiculing the participants of this thread that they are wasting their breath.
So my question is, if Rails' own core team and authors of popular tools/platforms that Rails depends/runs on can't influence a change to the framework, is "opinionated" still a motto we should stand behind?
Update: I forgot to state the most important reasons why I think these changes are harmful.
They are harmful because it teaches wrong usage of 3rd party tools such as Bundler and rbenv. As a maintainer of rbenv, I'm going to be sad when newcomers to Ruby/Rails experience problems with ruby-local-exec, start googling and discover that this comes from a project called rbenv and will think that is the source of their woes. Same goes for Bundler. Same for Heroku.
There was a problem hiding this comment.
@nirvdrum I apologize, I didn't know that rbenv would set that shebang line to jruby since I looked at mine it seems like they got set to env ruby_nonexec_wrapper, which comes with bundler, and later then have a shebang line to env ruby
[~] ruby -v
jruby 1.7.1 (1.9.3p327) 2012-12-03 30a153b on Java HotSpot(TM) 64-Bit Server VM 1.6.0_37-b06-434-11M3909 [darwin-x86_64]
[~] head `which rails`
#!/usr/bin/env ruby_noexec_wrapper
#
# This file was generated by RubyGems.
#
# The application 'rails' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
[~] head `which ruby_noexec_wrapper`
#!/usr/bin/env ruby
original_file=ARGV[0]
ARGV.shift
$PROGRAM_NAME=original_file
require 'rubygems'
begin
require 'rubygems-bundler/noexec'
rescue LoadError
[~]
There was a problem hiding this comment.
[~] which ruby
/Users/sikachu/.rvm/rubies/jruby-1.7.1/bin/ruby
[~] env ruby -v
jruby 1.7.1 (1.9.3p327) 2012-12-03 30a153b on Java HotSpot(TM) 64-Bit Server VM 1.6.0_37-b06-434-11M3909 [darwin-x86_64]
[~]
So I was assuming that regardless of the MRI/JRuby, env ruby will return the Ruby interpreter for you.
There was a problem hiding this comment.
To be honest this entire thread is indicative of a larger issue: bundler's binstubs. Without getting into too much detail: wouldn't it just make more sense to have your $PATH modified dynamically for each project you are working on? Then we can avoid the bundle exec // binstubs issue altogether. And, I agree, this is something that should not be in version control.
I'm fairly new to the Rails world and come from Python/virtualenv. While I much prefer the Rails way for 99% of things, virtualenv was pretty radical. Over yonder, we would create a virtual environment that had it's own version of Python, it's own place for 'gems' (referred to the site-packages directory in Python). It provides an interface to 'workon' a project (the command is called workon) which loads up that virtual environment. All it really does is modify your PATH. In this way, Python itself, it's libraries, third party libraries, etc... are all isolated to that one single root directory. And each developer has their own virtualenv so they can use slightly different tools if they'd like, without causing problems for anyone else on the team.
There was a problem hiding this comment.
Stop talking about this as a Bundler/binstubs/platform/ruby env issue.
It should not be the Rails default to version control bin/. Only in specific, probably wrong, cases should you want to do that.
This is absolutely an opt-in choice, not an opt-out.
How is this still not reverted?
There was a problem hiding this comment.
I know that people are frustrated about @dhh decision on this, and the fact that this doesn't get reverted yet — I do too. However, let's not trying to make this into another drama. I think everyone clearly stated their point as @mislav has summarized it.
@dhh, from everything we just said, would you mind revert this and maybe we can figure out a better solution together?
There was a problem hiding this comment.
FWIW, I've always wondered why rails new runs bundle install by default. Yes, I know you can disable it using the --skip-bundle flag. I also know that if you're unhappy with the Bundler defaults coming with Rails, you can just rm -rf .bundle and invoke it with whatever settings please you.
However, looking at the above discussion, wouldn't it be wiser to simply not invoke Bundler by default and leave that up to the developer setting up their new application/the newly cloned repository?
There was a problem hiding this comment.
I want to reiterate this from @mislav:
Also, during this discussion we've received input from notable figures:
- The author of Bundler expressed his disapproval of Bundler-generated binstubs getting version-controlled;
- The author of rbenv said that the coupling with rbenv is not necessary;
- An employee of Heroku is concerned about people's apps not functioning anymore on their platform;
- At least 3 Rails Core team members are participating, not happy with the change and proposing alternatives.
Yes, it's an organizational problem if all developers can't share the same development environment, but I really don't think Rails should be making that decision for an organization.
- Young startups may not be able to afford all the same equipment for employees or virtualization. Furthermore, Rails has always been a "hit-the-ground-running" framework. This change increases the probability of merge conflicts 10-fold.
- Older companies with technical debt may rely on legacy systems (cough Oracle) that don't work on new development machines (cough OSX Mountain Lion). The binstubs that get compiled against Mountain Lion are different for a lot of gems.
While I agree that it's an organizational problem to have differing development environments, its also a problem that Rails shouldn't be making the decision.
@dhh write another book if you want to fix organizations, don't break Rails.
Now, let me give you a real use case - education. I'm the head teaching assistant for an Application Design and Development course at Carnegie Mellon. We use rails to teach students principles like MVC, database abstraction, and web apps in general.
They use their own personal laptops
That means we have to support Windows, Linux, Mac OS (Leopard - Mountain Lion), CentOS, and pretty much any other platform. They work in teams and pair program for many parts of their assignments and phase reports. I'm pretty sure it's not even possible to share binstubs (for many gems) between Windows and Linux.
Possible solutions:
- Make everyone use vagrant
- Make everyone buy a brand new Mac (ha!)
- Have everyone gitignore
bin
OR
Listen to the very highly-regarded authors and community members and ignore binstubs.
The argument:
Also, if you really do insist, you can always add this to .gitignore yourself.
goes the other way too: You can always force add those files with git 😃
There was a problem hiding this comment.
The education part of this is very big. I had a class of 3 last summer (small classes of beginners is good), and we had three different operating systems present - Windows 7, Windows XP and a Linux install. I'll confuse my next group of students even more when I have to get up and say "Because of how rails does things, you have to do a lot of different hoops just to get the basic application that we'll be dissecting to run."
Particularly when I just finished telling them how awesome rails is for having sane defaults, and how awesome ruby is for 99% of the time not caring about what OS you're running.
There was a problem hiding this comment.
@jrgifford Rails is a major player in education, and I think that often goes overlooked. It's a great starting place for beginner programmers (half because Ruby is awesome and half because Rails has had sane defaults).
There was a problem hiding this comment.
Don't want to beat the dead horse here, but I just want to add that myself and another are working on a small project. His mac died, and it's not really practical for him to buy a new mac right now, so he was considering getting the rails app going on his windows machine. Something like this could cause a nasty headache to many who don't always check the gitignore, when really it benefits so few, and adds a very small convenience to a well organized team. So many people in here are concerned, and would have to configure their initial rails setup to ignore the bin stubs.
There was a problem hiding this comment.
@dhh if rbenv is the only Ruby selection tool endorsed by Rails then why not just say so? Your passive approach is generating insane amounts of discussion.
There was a problem hiding this comment.
I don't care about the .gitignore, but why is there now a dot at the end of each comment except one?
There was a problem hiding this comment.
a bunch of thin-skinned pansies. count yourself lucky dhh didn't gafter anyone as he reverted the change.
this is what he should have written:
Dozens of
languageframework "proposals" are now generated weekly by people incompetent to the task. Sometimes the author is quietly tolerated by the community until their attention to the issue wanes. Sometimes a more persistent author attempts to pursue their proposal, and eventually comes to realize that they are out of their depth. Occasionally an individual with a complete lack of talent never comes to appreciate the futility of their approach, and attempts to recruit support from a wider community of amateurs.
There was a problem hiding this comment.
Without engaging in the nerd-rage fest, here's a summary of the intentions that all the people who are actually willing to get into the kitchen have signed on with:
/u/apps/example/bin/rake should run the rake from /u/apps/example/Gemfile.lock, use the ruby declared in /u/apps/example/.rbenv-version (or .ruby-version), and not care whether it's run from the app directory or not (so no need to cd in a cron command). These binstubs should be available for the major tools like rake, rails, bundle, and cap by default and require no configuration to setup. They should strive to be as cross-platform as possible.
That's the mission and we have some great contributors working on making it so.
Feel free to keep the festival going, though. No reason to stop just because software is being made in the background.
There was a problem hiding this comment.
@sethvargo Mislav is part of the team making it work.
There was a problem hiding this comment.
Your app's ./bin dir will be where executables live: rails, bundle, rake, cap, etc. That'll "just work" in dev and production. Bundler will install binstubs selectively: you pick what you want.
Heroku is on board ❤️ Bundler is on board ❤️ rbenv is on board ❤️ Rails is on board ❤️
There was a problem hiding this comment.
Well I definitely feel like I've been heard and that my point has been well received. No way have I been insulted at all.
There was a problem hiding this comment.
I'm glad for how it turned out. There were some harsh words thrown around, but let's not focus on that. The main thing to know is that people are working on addressing these issues; so our voice was heard after all.
The reason why the decision process is not transparent enough is because Rails Core prefers to discuss issues in their private chat room instead of here on GitHub.
There was a problem hiding this comment.
Thanks, everybody! This tour of the sausage factory was highly informational and entertaining.
There was a problem hiding this comment.
Our team has rbenv devs and rvm devs, comfortably working side by side, like sheep and wolves lying together. Nobody told us until now that it was madness, so I fear a sudden predator-prey conflict is about to emerge... Thanks a lot, DHH! ;)
There was a problem hiding this comment.
I'm not going to even touch the drama, because we all have opinions. But there's a question no one really asked, which is: What was the motivation behind this? I'm not judging, I just want to be in the know. Was it to make something easier? Was it to incorporate a little more of Bundler into Rails? Was it to codify a common pattern that you 37signalers use? Was it to combine script/ with bin/? What is the future plan here... that's all I want to know.
There was a problem hiding this comment.
There was a problem hiding this comment.
@dhh, what is the reason to check binstubs in source control? You still have to run bundle install which generates binstubs automatically.
There was a problem hiding this comment.
@mcmire specifically this comment.
There was a problem hiding this comment.
There was a problem hiding this comment.
Of course, not everyone is king of Rails and thus irrevocable change access to rails/rails, and so the rest of just make binstub generation a part of the build process.
Crazy world.
There was a problem hiding this comment.
@dhh, it does if you add the option to the global config (~/.bundle/config). You can also specify shebang there suitable for your machine. These settings aren't project specific, are they?
There was a problem hiding this comment.
❤️