Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Default rvm_project_rvmrc to off, set rvm_project_rvmrc=1 in ~/.rvmrc…

… to enable.

Oh wow, you mean you could toggle it??? Yes. Always could. Wow I should have asked!!
Yes... yes you should have... Amazing how much you learn by simply asking a question...
commit 9a9fef58731e822b03789445a859fcdb69e57fff 1 parent 1be526b
@wayneeseguin wayneeseguin authored
Showing with 8 additions and 6 deletions.
  1. +1 −1  scripts/cd
  2. +7 −5 scripts/functions/installer
View
2  scripts/cd
@@ -2,7 +2,7 @@
# Source a .rvmrc file in a directory after changing to it, if it exists.
# To disable this fature, set export rvm_project_rvmrc=0 in $HOME/.rvmrc
-if (( ${rvm_project_rvmrc:-1} > 0 ))
+if (( ${rvm_project_rvmrc:-0} > 0 ))
then
__rvm_after_cd()
{
View
12 scripts/functions/installer
@@ -108,10 +108,13 @@ upgrade_notes()
Upgrade Notes
+ * Set rvm_project_rvmrc=1 to enable project switching on cd, note that this
+ will override cd with a function (bash) and/or hook into it (zsh)
+
* rvm_trust_rvmrcs has been changed to rvm_trust_rvmrcs_flag for consistency
- * Project rvmrc files are now checked for trust whenever they change, as promised by
- the note displayed during the review process
+ * Project rvmrc files are now checked for trust whenever they change, as
+ promised by the note displayed during the review process
* Ruby package dependency list for your OS is given by:
rvm notes
@@ -119,9 +122,6 @@ Upgrade Notes
* If you encounter any issues with a ruby 'X' your best bet is to:
rvm remove X ; rvm install X
- * If you wish to have the 'pretty colors' again, set in ~/.rvmrc:
- export rvm_pretty_print_flag=1
-
* If you see the following error message: Unknown alias name: 'default'
re-set your default ruby, this is due to a change in how default works.
@@ -130,6 +130,8 @@ Upgrade Notes
chmod +x $rvm_path/hooks/after_use_[hook_name]
chmod -x $rvm_path/hooks/after_use_[hook_name]
+ * Set rvm_project_rvmrc=1 to enable project switching on cd, note that this
+ will override cd with a function (bash) and/or hook into it (zsh)
"
}

3 comments on commit 9a9fef5

@mipearson

Woo commit wars. I bitched about this commit on twitter, but then felt it wasn't fair to bitch about it "behind your back" as it were.

disclaimer: I use RVM pretty heavily. Last role I had JRuby, MRI 1.8.7 and MRI 1.9.2 projects on the go at the same time, would have been impossible to manage otherwise. I never cared that it overrode cd - if that had caused me problems, it would have been a clue to get out of the damn shell anyway.

but

Either functionality stays the same and you can say "yes, you can use RVM in production" or functionality changes and it's a development tool for developers to recover from when stuff does change. It can't have it both ways, especially when you bring any kind of configuration automation in to the mix.

If I had depended on .rvmrc as part of my deployment (as I probably would have if I'd been using RVM to manage multiple rubies on a prod setup: think puppet/chef/system ruby vs latest+greatest), this commit would have broken deployment on any new system that was provisioned.

Is the recommended solution here to lock to particular "version" of RVM, as the install script allows us to do? I vaguely remember you discouraging this practice.

@fnichol

@mipearson, did you notice the version released bumped to 1.7.x? Just like any other library or package you need to keep on top of version changes. Auto-provisioning the latest versions of everything is great...after testing. Typically if I'm provisioning a set of production nodes I'll set the same tagged release of RVM across all nodes. Same thing when refreshing configuration. It's also a good idea to either have your /etc/rvmrc version controlled or part of the configuration management system.

Otherwise, am I missing something?

@wayneeseguin

@mipearson, I am with @fnichol on this one, which is also why I bumped the version to 1.7 as it is a functionality change by toggling defaults.

You can lock the project rvmrc setting it in .rvmrc regardless of the version of RVM.

As for in production, In my opinion, you should stick with a release tarball and use qa/staging cycle to update the version of RVM as well as any other software.

Please sign in to comment.
Something went wrong with that request. Please try again.