Skip to content
This repository
Browse code

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...
  • Loading branch information...
commit 9a9fef58731e822b03789445a859fcdb69e57fff 1 parent 1be526b
Wayne E. Seguin authored August 15, 2011
2  scripts/cd
@@ -2,7 +2,7 @@
2 2
3 3
 # Source a .rvmrc file in a directory after changing to it, if it exists.
4 4
 # 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 ))
6 6
7 7
8 8
12  scripts/functions/installer
@@ -108,10 +108,13 @@ upgrade_notes()
108 108
109 109
 Upgrade Notes
110 110
+  * 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)
111 114
   * rvm_trust_rvmrcs has been changed to rvm_trust_rvmrcs_flag for consistency
112 115
-  * 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
115 118
116 119
   * Ruby package dependency list for your OS is given by:
117 120
     rvm notes
@@ -119,9 +122,6 @@ Upgrade Notes
119 122
   * If you encounter any issues with a ruby 'X' your best bet is to:
120 123
     rvm remove X ; rvm install X
121 124
-  * If you wish to have the 'pretty colors' again, set in ~/.rvmrc:
-    export rvm_pretty_print_flag=1
125 125
   * If you see the following error message: Unknown alias name: 'default'
126 126
     re-set your default ruby, this is due to a change in how default works.
127 127
@@ -130,6 +130,8 @@ Upgrade Notes
130 130
       chmod +x $rvm_path/hooks/after_use_[hook_name]
131 131
       chmod -x $rvm_path/hooks/after_use_[hook_name]
132 132
+  * 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)
133 135
134 136
135 137

3 notes on commit 9a9fef5


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.


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.

Fletcher Nichol

@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?

Wayne E. Seguin

@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.