And update the README to explain to copy it back if you choose to use RVM.
I'd also be open to changing the ruby version in the .rvmrc.example to 1.9.3.
I have to ask - what does moving to 1.9.3 add? I'm kind of on the fence on that one... then again, I'm of the "if it works, it works, why move to something else if we don't gain from it" opinion. :)
Because it already works with 1.9.2 and 1.9.3. We use CI to maintain 1.9.3 forward compatibility. So, why not use 1.9.3?
Rails 4 will only support 1.9.3....
Ah, didn't know that @steveklabnik. Ok, guess that's a good enough reason to update the .rvmrc.example.
Honestly, I don't understand why this change is being made in the first
Also, since we're targeting heroku for deployment, they now use the Bundler
ruby select method now...
@locks was all "ruby 1.9.2 whyyyyyyyy"
I see. Well, in that case can someone update the .rvmrc.example to 1.9.3?
I didn't do that since I wasn't aware of any specific reasoning (I know,
that makes me sound silly).
I meant "why do we ignore .rvmrc"
It seems to be standard practice. Last I checked, most projects seem to
ignore the .rbenv and .rvmrc files.
those projects are stupid.
For more: https://rvm.io//rvm/best-practices/
What do you gain by using a project specific rvmrc that you don't have with bundler?
.rvmrc files are about providing a clean room per project. Bundler is about managing application dependencies and load paths. They're two different things.
Oh, and 1.9.3 is generally more performant than 1.9.2. Couple of good optimizations in there.
Without a .rvmrc, what state is the room? dirty?
I think the value of .rvmrc is more in gemsets than in selecting a ruby
to use. I'm a little behind on Bundler's added ruby impl selection, but
does it also do gemsets?
@wilkie come on, you know exactly what I mean.
@colindean no, it does not do gemsets.
Well, the only thing the rvmrc is going to do is a rvm --create email@example.com because that's all you need to do to create a 'clean room' as it was put.
rvm --create firstname.lastname@example.org
I wonder why the trend is to commit a dotfile to a repo (which is weird in and of itself) and have it force that to happen on a cd and typing 'yes' when they can just type that. Can't we as a culture just assume people are smart? And have them use the tools they have installed for the purposes the tools were designed for?
I don't get it.
If we don't trust them to type out the create command, for some reason, then don't we need a rbenv script to issue one strikingly similar command as well? For people who like rbenv over rvm, yanno? It happens. :)
Regardless, if you want to not type that simple command you should already know how to use, well, you can copy the rvmrc back from the example and then have it magically type it in for you. :P
The dot file is a full shell script, actually, so it can be used for more
complicate setups as well.
Anyway, I'm not getting into this argument, do whatever you want, I just
couldn't let this go by without my 👎
As much as I ❤️ rvm, there are people who don't and choose to use a different way to manage their environment.
To be as friendly as possible to all kinds of contributors, I don't think we should force/advocate/strongarm people into using our favorite.
If you don't have rvm installed, then this file does nothing, so nobody's forcing anyone.
IMHO .rvmrc files are checked into development repos for the same reason that we check in the Gemfile: because it would be annoying to have to maintain separate files on every single developer's box, and for those that use it, it is very useful. For those that don't use it, the .rvmrc does nothing.
I know of a person who has rvm installed but doesn't always want to use it, and this person is annoyed by the gemfile trust message that comes up when you cd into the directory. We can definitely debate whether we should care or not, but I know of this case.
Then there's @locks' case-- he uses rvm, we support 1.9.3, he wants to use 1.9.3, but our .rvmrc was forcing 1.9.2. I think this case points towards the usefulness of an example that people can make their choices with, similar to the way we provide a config.yml.example.