While working with LocomotiveCMS using Rubinius I ran into a bunch of syntax errors. All were along the lines of expecting '|'. No one was posting issues about this so I figured I would ask: How do I resolve these issues? Is this a problem with Rubinius?
First off, LocomotiveCMS only supports the "last version of Ruby" (Ruby 1.9.2 and greater). View the requirements section.
Rubinius defaults to Ruby 1.8.7 (view on rvm.io). If you look at the lines where most of these syntax errors occur like in app/models/locomotive/page.rb they are most likely in "lambdas" which aren't supported until Ruby 1.9.
To resolve, you can make Rubinius (rbx) use Ruby 1.9 in two ways:
Use rvm to reinstall rbx using Ruby 1.9 as the default:
rvm reinstall rbx --1.9
Note: if rvm complains about bad arguments upgrade rvm using rvm get master or rvm get stable.
Or, if you don't want to completely reinstall rbx, you can set an environment variable in the directory which you'll be calling Rubinius, like in the rails root directory.
export RBXOPT=-X19
You can check that the environment variable is set by using rbx -v to check the Ruby version. It should return something like:
rubinius 2.0.0.rc1 (1.9.3 release ...)
Note: If you are running Rubinius from another directory you will need to set this option again.
Related
I use rbenv but other team members use RVM.
When specifying the ruby 2.x.x version in the Gemfile I’ve been doing this:
ruby ENV['RBENV_VERSION'] || '2.2.4'
which grabs the current version I’m using from rbenv and uses it for the Gemfile. However, in production, it is not present and uses the specified version after ||.
I’ve been searching for a similar way to do this in RVM, the ultimate goal being to set up a Gemfile where all developers can use their local version of Ruby and a concrete version is specified for production.
This would allow developers to use rbenv or RVM for a project as well as not need to install new versions of Ruby every time they work on a project with a version they don’t have installed.
Are there any RVM users that can give me an equivalent to ENV['RBENV_VERSION'] for RVM? I’ve been searching a lot and haven’t found anything I like.
The best answer I can see is having RVM users specify the version via an environment variable name agreed upon by the team and used like "Specifying a Ruby version via the environment" as well and use that instead in the Gemfile.
To get the current Ruby version from any RVM instance, you can query it using this method:
rvm list default string | sed s/ruby-//
You can also use the RVM prompt tools to query the current version
rvm-prompt i v | sed s/ruby-//
or
rvm-prompt i v p g | sed s/ruby-//
depending on how detailed you want to allow. Docs for the rvm-prompt command can be found in "rvm-prompt".
If the user chooses to leave RVM at its default version, you get that version reported, but if the Ruby version has been changed in RVM, you get the currently chosen version.
You can chain this in any way that ENV['RBENV_VERSION'] is used, such as:
`rvm list default string | sed s/ruby-//` || 2.2.4
This will choose the current RVM Ruby version or 2.2.4 if RVM doesn't show a version.
Note that RVM has to exist (or at least something called rvm has to be available as an executable). If not, an additional script wrapper may be needed to handle the situation in which it doesn't exist and degrade gracefully.
Personally, I love having it available everywhere, including production environments. It's the very first thing that I install on a new OS instance, even before the text editor, and the second thing that I do is install the appropriate Ruby version with RVM.
Every time I type ruby and hit Enter at my terminal, it just hangs for seemingly forever. This is happening for the default Yosemite install and after I installed with rbenv, using Homebrew (which works fine), using "Ruby on Rails development setup for Mac OSX".
My current Ruby version is 2.2.2, ruby -v works, and I didn't have this problem when I was using OS X Mavericks.
Has anyone else had this problem and/or found a solution? My google-fu doesn't seem to be strong enough.
When you enter ruby at the command-line, it's supposed to "hang forever". It's waiting for you to give it instructions. You can use CTRL+D to get it to stop waiting:
> ruby
puts 1 + 1
2
I then did CTRL+D and returned to the command-line prompt.
Instead though, we don't use Ruby like that. If we want to use it interactively, we use IRb which comes with Ruby. It's the "interactive" Ruby:
> irb
Welcome to IRB. You are using ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin13]. Have fun ;)
>> 1 + 1
2
>> 'foo'.squeeze('o')
"fo"
If we want to run a Ruby script, we use something like:
ruby /path/to/script
and Ruby will load and run it.
I'd recommend reading some Ruby tutorials and learn how the language works before trying to use Rails. Rails uses deep Ruby magic and how Rails works will be unfathomable to you until you do understand better how Ruby is used and how it works and what it can do.
If you're using rbenv to manage your Ruby, then when you enter rbenv versions you should see the Rubies it manages listed:
rbenv versions
system
1.9.3-p551
* 2.2.2 (set by /Users/tinman/.rbenv/version)
If you don't, either rbenv isn't in control of Ruby, or you haven't installed any using rbenv. rbenv global system will tell it to use whatever you have installed by default in the system, based on your PATH.
rbenv's documentation and built-in help go over this so if the problems continue then you need to closely examine your install and setup, because 90% of the problems we see using a sandboxed Ruby are due to people not paying attention to the directions, or using the wrong ones, and not completing the installation.
I'm not sure if this belongs here or somewhere else (SuperUser?) but anyway:
I've got two Ruby scripts, one which requires Ruby 2.0 (A) and another which requires 1.8 (B). A needs to call B with a forked processes. A is something like this:
require "fileutils"
require "json"
...
`name_of_B`
B is an executable script with a shebang, starting like this:
#!/Users/user_name/.rvm/rubies/ruby-1.8.7-p374/bin/ruby
require 'rubygems'
require 'json'
...
I use RVM to manage my Ruby versions:
> rvm list
rvm rubies
ruby-1.8.7-p374 [ i686 ]
ruby-1.9.3-p448 [ x86_64 ]
=* ruby-2.0.0-p247 [ x86_64 ]
I run A with:
> ruby name_of_A
but end up with:
/Users/jacobevelyn/.rvm/gems/ruby-2.0.0-p247/gems/json-1.8.1/lib/json/ext/parser.bundle: [BUG] Segmentation fault
ruby 1.8.7 (2013-06-27 patchlevel 374) [i686-darwin12.5.0]
Any thoughts on what I can do? I don't know a whole lot about gems but it appears that B tries to look at gems installed under Ruby 2.0, rather than 1.8. (Yes, I've run gem install json under 1.8 already.) Obviously the scripts are more complicated than they appear here and absolutely cannot be ported or combined (this doesn't mean I don't want to, it means I can't for my use case), otherwise I would.
you need to change the shebang to:
#!/Users/user_name/.rvm/wrappers/ruby-1.8.7-p374/ruby
it will not only use that ruby but also its gems.
in case you use bundler (Gemfile) you might also need to wrap the command invocation in:
Bundler.with_clean_env do
...
end
which will reset loaded bundler environment
Call:
result = `\path\to\ruby_1_8 \path\to\ruby_1_8_script.rb`
This will use the correct ruby binary to execute the script that expects it. The result is saved into the var.
You can call which ruby to find the version of the ruby in your current directory. Go to your project / source dir and call it to see the version (presumably Ruby 2) that you're using for the main app. Then, go to your old project / repo (associated with the 1.8 script) and run it again. Hopefully that will show you the path to Ruby 1.8. If not, try it from root (/). Or use RVM to confidently switch to Ruby 1.8 and then call it there to get the path.
I've never used RVM much. If it is confused, and filters things through the wrong gem set, etc, then you may need instead to switch to rbenv. Also, you may need to use its own functions to display the true path to the Ruby 1.8 binary (i.e. maybe it messes with which?) Again, I don't RVM.
When logged in as root and I type ruby -v centOS server reports 'ruby 1.9.3p392'. This is what I want.
But if I put rvmsudo ruby -v then I get 'ruby 1.8.7'. I do not want to use this older version, it is causing problems for my gitlab install.
I would like to remove it and make sure only v1.9 is used, how can I do this? Or should I leave it there but try and require certain users to use a different version?
Also, in case doing this messes anything up, is it possible to either;
a.see if anything on the server requires v1.8?
b.reverse the uninstall if it causes a problem?
Before uninstalling, take note of the patch level of 1.8.7 just in case. rvmsudo ruby -v should return something like ruby 1.8.7p234. The p#{num} is your patch level.
You should be able to uninstall 1.8.7 with rvm uninstall 1.8.7 (or possibly rvmsudo uninstall 1.8.7). This version of Ruby shouldn't be used by anything on the system other than code you've written, so it should only affect your applications and scripts.
The best way to tell what else would be using 1.8.7 is to look for scripts and crontabs that are owned by the user that rvm is running under. I'm not sure there's a tool that can evaluate it for you.
The best way to roll back in case of an emergency is rvm install 1.8.7-p#{num_from_above}. Alternatively, if you're on a platform like AWS or have rsync backups enabled, you might consider taking a snapshot that you can roll back to if you get in over your head.
Hope that's helpful!
Try setting default
$ rvm --default use 1.9.2
$ ruby -v
#ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]
to remove you can use:
sudo apt-get remove ruby 1.8.7
Docs here & here
As you mentioned the ruby version output for root is ruby 1.9.3p392 in my understanding you will not have any problems.
Sure, you can have more than one version of ruby installed and find them under ~/.rvm/rubies. Also there you can find out the default version which is used. For more information you can have a look here: set default ruby where it explains how to set a default ruby and how to reset to the systems default.
You can uninstall cocoapods and install cocapods in the right directory.
sudo gem uninstall cocoapods
sudo gem install -n /usr/local/bin cocoapods
Bundler 1.2.0.pre includes a new "ruby" DSL option. According to Heroku's documentation, they use this new Gemfile syntax to control which ruby version is used when you push your app.
Being pre-release, documentation for the new Bundler option is fairly thin on the ground at the moment, and the Bundler 1.2 roadmap simply lists it as "ruby version check".
My question is: currently I use a one-line .rvmrc file in most of my projects, in which I only specify the ruby version for that project (eg. rvm ruby-1.9.3). I don't use RVM gemsets or anything else (I prefer to vendor all of the required gems within the project, and let Bundler manage the dependencies).
Given my trivial RVM config, will the new "ruby" option in Bundler's DSL mean I no longer need to specify a .rvmrc file at all? Or are they two different things?
(I do like the fact that RVM automatically switches the ruby version when I cd into my project...not sure if Bundler would do that, or if it just warns when the current version doesn't match?)
the new ruby is a function and it will allow anything that finally evaluates to a string.
Unfortunately o read it you would need to use a bundler command which assumes you already have a ruby.
Instead RVM gives you two ways to defining ruby in Gemfile:
1) ruby "1.9.3" - simple strings
2) #ruby=1.9.3-p125 - a comment when you want to use ruby code for ruby or when you want to specify patchlevel or gemset!:
#ruby=1.9.3
ruby ENV['RUBY_VERSION'] || '1.9.3'
Will allow bundler to work with any ruby loaded by RVM but by default will use 1.9.3 from #ruby=