I have just started working on a ruby project and I notice that I have to specify the ruby version to use globally. For instance, I am using chruby to change the ruby version to use and I can set it directly at this file called .zshrc.
But if I have a multiple apps with different ruby version, then how do I handle it? It doesn't make sense if I keep changing the version to use at .zshrc file every time I want to run the other app.
Since it's a shared project so I cannot just change the version used in the app. Thank you.
In chruby, this feature is called "Auto-switching".
If you want chruby to auto-switch the current version of Ruby when you cd between your different projects, simply load auto.sh in ~/.bashrc or ~/.zshrc:
..
chruby will check the current and parent directories for a .ruby-version file.
https://github.com/postmodern/chruby#auto-switching
Related
This happens when I run npx react-native init AwesomeProject.
When I check the system ruby version with ruby -v, it is already 2.7.5. ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-darwin21]. Anyone has any idea for this problem?
Sounds like you’re using rvm to manage Ruby versions.
You need to install and run the correct version, not delete the current.
Something like
rvm install 2.7.5
rvm use 2.7.5
The Gemfile Isn't (Directly) Your Issue
The Gemfile is irrelevant to solving this issue. It's just triggering it because your in-project Ruby version isn't matching what RubyGems (via the Gemfile or Gemfile.lock) expects as a constraint. It could be a minimum version, an exact version, an approximate version, and so forth. There are a lot of ways to specify version constraints in a project, and the Gemfile is just where the constraint-related exception is being raised by Bundler.
You could possibly make the problem go away simply by removing the requirement for a later version of Ruby from the Gemfile or gemspec, removing the Gemfile.lock, and re-running Bundler. However, if your code relies on features in a later version this will just create other problems for you. You really ought to uncover what's changing your Ruby environment within the project directory.
Dotfiles
There are a lot of reasons this could happen, but if your system Ruby is 2.7.5, then you need to check your project directory for various dotfiles like:
.ruby-version
.rvmrc
~/.rvmrc
.envrc
.env
or various other files that affect your shell environment or whatever Ruby version manager you're using. Most Ruby version managers respect .ruby-version, but some version managers use other files, including defaults or shims that may be set elsewhere. IDE's also often have their own project-specific configuration files, too, and they can sometimes be set to override the project's standard settings.
Also, make sure to check your Gemfile.lock and *.gemspec in addition to the Gemfile itself, in case something is being specified there or constrained by some other dependency.
Inspecting Environment Variables
You should also look at the Ruby- and RubyGems-related environment variables from your project directory to see how various values are set within the project. For example:
printenv | grep -E '^(RUBY|GEM)' | sort
Shebang Lines
In addition, you should check your shebang lines in any executable Ruby or shell scripts you're relying on to see whether a specific non-system Ruby is being invoked. For example:
grep -Enr '^#.*ruby' *.rb | grep -F '.rb:1:'
will find all the shebang lines that properly appear on the first line of a Ruby file. This will either point to a specific Ruby like #!/usr/bin/ruby or might be using a PATH lookup with #!/usr/bin/env ruby.
Shell scripts might be harder to inspect, as there may be calls to other executables or even an exec command, so you'll need to be more liberal with your grepping if you are looking for an interpreter call further down than the shebang line.
Checking PATH Order
In the case of #!/usr/bin/env ruby, you should inspect your PATH environment variable to see why the Ruby you want isn't being called first. Using which -a ruby (if supported by your OS) will show you all rubies in your PATH in the order they would be invoked by the shell. It's possible that you're simply calling an unexpected Ruby version that comes first in the PATH.
I have no knowledge in Ruby, but I need to run some tests in it. The code is in Ruby and Cucumber. I use intellij on Mac. When I first open intellij cucumber step definition where not recognised from feature file. In terminal I got:
Required ruby-2.1.2 is not installed.
To install do: 'rvm install "ruby-2.1.2"'
but
$ which ruby
/Users/myuser/.rvm/rubies/ruby-2.4.1/bin/ruby
so I run the install command as suggested and now I get
$ which ruby
/Users/myuser/.rvm/rubies/ruby-2.1.2/bin/ruby
Now my feature files connected to step definition as well. I will appreciate if anyone could explain me what happened. What prompted me to downgrade the version of Ruby and how it fixed cucumber.
Make sure you have ruby 2.1.2 set in File -> Settings -> Languages & Frameworks -> Ruby SDK and Gems
What I suspect is happening is you have run rvm use 2.1.2 in the terminal but when your IDE runs something it is using the ruby version set in the settings.
You probably have a .ruby_version file in the project root directory. This will enforce a specific version of Ruby. So the person who put it there is who to ask why the version was restricted like that. There may have been a good reason, such as that's what is being used by all your users.
It has nothing to do with Cucumber. rvm has some kind of operating system hook, I think, that runs whenever you cd into a directory. It looks for its special control fiels such as .ruby_version and .rvmrc file. This page describes this in more detail: https://rvm.io/workflow/projects.
Not wanting to commit to e.g. .rvmrc for specifying the ruby version.
If your project is using a Gemfile you can set it there too:
ruby '1.9.3'
This is of course 'per project' and not global. Heroku uses it that way.
In the top-level directory of your project, create a file named .ruby-version containing only the version of ruby you want to use, e.g.
2.1.0
You can sometimes also specify system (known example: MacOS).
I've just updated RVM, and in place of the old .rvmrc, it auto-created .ruby-gemset and .ruby-version.
I've always had .rvmrc files with contents like rvm use --create default#project_name. However, .ruby-version contains the specific Ruby version I'm running rather than default. I'm hesitant to check this in.
Also, I heard someone say on a podcast that one shouldn't check in .ruby-gemset because others may have their own preferences about how to name gemsets.
When should or shouldn't I check in .ruby-gemset and/or .ruby-version?
Specifically:
What are some of the tradeoffs?
How does the type of project affect the decision (for example, applications vs gems)?
If they should be checked in, how does the type of project affect what should go in these files?
Citations from from the creators of tools like rvm, rbenv, etc would be appreciated in an answer.
For standard projects
Check in .ruby-version if your project depends on a ruby like ruby-2.0.0.
Check in .ruby-gemset only if your team agreed on it.
Add .rvmrc to .gitignore so anyone can override .ruby-* files settings with .rvmrc.
For gems
Check in .ruby-version with ruby-1.8.7 only if your project still targets ruby 1.8.7, otherwise check it in only if your gem requires it.
Do not check in .ruby-gemset.
Checking in .rvmrc, .ruby-version or .ruby-gemset?
FOR:
Your project has different branches (say a RubyGems project supporting Ruby 1.8, 1.9 and 2.0 versions). Its better to check in this file, so that your developers don't have to keep on editing these files when they switch branches. The same doesn't apply for an application though, where you'll mostly be working on only one Ruby version.
Same case as above, but say you are running a CI server (say TeamCity/Jenkins/...) which automatically just runs rake spec for every check-in. You don't want to create separate build pipelines for each branch, just for the sake of having a separate rvm use ... for each branch. You just want the Ruby version selected automatically depending on the branch
You have tight control over the environment and all the developers. You either don't need or dictate that they use the same ruby and gemset
You are using Phusion Passenger or Capistrano, which automatically read .rvmrc files and chooses the right ruby for deployment/hosting
Also refer RVM Best Practices
AGAINST:
You can compile your own Ruby in RVM, with some experimental patches, and give it a custom name.
e.g. rvm install 1.9.3 --patch railsexpress,falcon --name ruby-1.9.3-perf
In the above example, I've installed Ruby 1.9.3 with some great speed up patches (btw they are awesome), but rather than calling it 1.9.3, I'm calling it my own name. I would say rvm use ruby-1.9.3-perf whenever I need this. In this case, if the project has its own .ruby-version, then it messes up my environment. In my project, these patches are standard and we actively recommend those. But how developers name the resultant compiled Ruby is up to them
Similarly, people use different gemsets. Some don't use gemsets at all. Some share the same gemset with different (but similar) ruby projects. Given this, again a single .ruby-gemset also doesn't work for everybody
Your project has an obscure ruby version which just says 1.9.3. Your developers first installed the latest Ruby 1.9.3-p329. But they later just update RVM/Rbenv (since they're working on other projects). Their .rvmrc or .ruby-version just breaks, since the latest version of Ruby registered in RVM/Rbenv just changed from ruby-1.9.3-p329 to .ruby-1.9.3-p362, and it will say ruby-1.9.3-p362 not installed. This scenario tends to happen often.
As long as you specify a proper full name for your Ruby version (including patch level), you should be OK. Let's say your project's .ruby-version says ruby-1.9.3-p329. Its easy to compile your own Ruby with all these patches, and still just custom name it ruby-1.9.3-329 just so that the config files will pick up this ruby instead of the standard ruby.
I would include .ruby-version - you and anyone else working on the project, along with your servers, should be using the same version of Ruby.
.ruby-gemset.... up to you, I think.
I used the instructions at http://bparanj.blogspot.com/2010/06/installing-ruby-191-on-snow-leopard.html to install Ruby version 1.92 on my Mac running Snow Leopard. The only deviation is in step 3, which calls for .bash_profile to be updated. I have .profile, but not .bash_profile, in my home directory, so I added the export command to the last line of .profile. The installation completed successfully (with the same two warning messages as mentioned, which I too disregarded), as Ruby -v in a terminal prints
ruby 1.9.2dev (2010-07-02 revision 28524) [x86_64-darwin10.4.0].
When I run Textmate, however, cntrl-R invokes Ruby version 1.8.7, as it did before the 1.9.2 installation. In Textmate's Preferences-Advanced-Shell Variables, TM_RUBY is set to /usr/bin/ruby. The (binary alias) file 'ruby' has not been updated. What is the easiest way for me to instruct Textmate to use the newer version of Ruby? Please note my understanding of OS X is relatively limited.
What is the easiest way for me to
instruct Ruby to use the newer version
of Ruby?
I believe you mean "What is the easiest way for me to instruct Textmate to use the newer version of Ruby?"
Assuming that is the case, have you tried to edit the TM_RUBY shell variable to point to your newly installed version? According to the docs you referenced, it should be somewhere under /usr/local (most likely /usr/local/bin/ruby).
You can find out the location of your ruby installation by typing the following in your terminal window:
$ which ruby
/usr/local/bin/ruby
then perform the following to verify the version
$ ruby -v
Once you have the proper ruby path, in Textmate, double-click the 'value' of the TM_RUBY shell variable & type in the path to your 1.9.2 install.
Why not just create a .bash_profile file in your home directory?