Would it be safe to delete ruby from my mac (the version that came preinstalled), and replace it with a link to ruby1.9, and do the same with irb and gem?
Is there anything specifically that might be an issue?
I wouldn't delete it. Personally, I downloaded ruby's source and compiled/installed it under the /opt directory. Then I edited my path so that /opt/bin/ruby (irb and gem as well) had higher precedence than the system default. This way you can keep the system default and the newest version at the same time. Plus, if Apple ever does update their MacRuby version, you don't have to worry about losing anything or getting down-graded.
I manage this with bash aliases:
alias ruby18=/usr/bin/ruby
alias ruby19=/opt/ruby1.9/bin/ruby
alias ruby=ruby19
It's occassionally handy to have both versions installed, particularly for gems that aren't 1.9-ready.
You could rename the ruby 1.8 binary files to ruby1.8, irb1.8, etc... and then symlink your ruby1.9 files to become 'ruby'. This allows you to use 1.8 if you have a compatibility issue with a project, or you could even use a tool like ruby_switcher to go back and forth between the two very easily. http://github.com/relevance/etc/blob/3d607c8ac2f76077f27c3cbc0140b04a89f546be/bash/ruby_switcher.sh
I wouldn't altogether delete Apple's Ruby. It probably wouldn't hurt anything, but it is part of the system and it's not impossible that some things might expect that version (which includes, for example, RubyCocoa) to be there.
You could, however, install Ruby 1.9 into /usr/local/bin and put that ahead of /usr/bin in your PATH, so that is the default Ruby that gets called when you say ruby.
As a side note, you might try the well-respected Ruby Version Manager. It's there to help you manage several Rubies side by side.
Related
I am creating a gem and I have the suspicion that it may not work on certain Ruby versions. Is there a way to quickly check which Ruby versions it is compatible with? My current method is using RVM and switching to different Ruby versions to test, but that may be an inefficient way to do it. I was also wondering if I could narrow it down to a specific patch version.
#Matt Schuchard suggested the right way to do this (in the comment)
For example, you can check how to do this with GitHub Actions. You can test it not only for specific ruby version but also on different OSes
https://github.com/metanorma/metanorma/blob/master/.github/workflows/rake.yml
I've made a custom sient installer of Ruby 2.0 with some gems and extras, my installer expands all the Ruby files to c:\Program Files (x86)\Ruby, the interpreter (ruby.exe) is in the Bin folder, all is as normally but just it's not an original installation, I expand the files and I add the registry keys to associate files by my own, I can run Ruby as normally ever I want.
Now, is the first time that I try the JetBrains RubyMine IDE, and I can't found a simple guide which explains how to set the Ruby directory, seems that this IDE assumes that the Ruby installation is original and maybe takes a registry value from the original Ruby installer to know the Path or something, I don't know, but just I didn't see any help about how to set the Ruby directory manually.
(I have the same problem for PyCharm)
Anyways I've tried to set it from the Ruby SDK and Gems option, the dialog-box says "select Ruby interpreter Path", but I'm on the Path and it's not recognized, I mean that the Ok button still disabled:
Then I'm missing the right option anywhere? or really a professional and expensive IDE like this doesn't has support just to specify the location of Ruby in these circunstance where an user does not use the original Ruby installer? I really will think not.
In my experience it is more preferable to set your PATH environment variables appropriately instead of trying to locate executables on a per-app basis.
You can set your path so that the desired Ruby takes precedence over any other rubies and I am sure that RubyMine will pick it up (or just use ruby and let your PATH specify which to use).
On another note you might also want to have a look at a ruby version manager such as rbenv or RVM.
Update: Just tried to set manually a Ruby SDK in the latest version of RubyMine (6.3) and it worked as expected. I had, however, to expand the folder in which the binary resided (in your case bin), select the actual binary and then click OK. Have you tried that as well?
If you have two JRuby versions installed and one of them is not recognized:
Add both bin directories to your PATH (like in Kostas Rousis's answer above),
set JRUBY_HOME to the one version you want to use and
restart RubyMine.
In my case, I have the version 1.6.8 and 9.1.13.0 installed. Setting JRUBY_HOME to the newer version I can use both versions. However setting JRUBY_HOME to the older version, RubyMine only recognises the older version, even when I navigate to the newer version's folder. That's a really weird behavior but I'll take it. I still remember that it worked properly in earlier versions of RubyMine though (I'm currently at 2017.2.4).
I'm using rvm on Ubuntu 12 to manage ruby versions/gemsets. I am testing various projects and some gems won't work with certain versions of Ruby or with each other. Is it possible to find which version of ruby an app was written for, so I can set my rvm to use that version and get the right gems when I run bundle install?
You can lookup the gems on rubygems.org. They are supposed to list what version of ruby they are compatible with, but that may not always be kept up to date.
If that doesn't narrow it down, you can check the gem's CHANGELOG file on github.
In the end, you may have to just try a few. There's only a handful of versions in common use, so it's not like you have to try then all.
in my experience ruby 1.9.3 is most widely supported at the time of this writing. Ruby 2.0 and 2.1 would also be good to try. 1.8.7 is pretty old and will likely give you a good bit of trouble, but it was the standard for a long time.
Why should I/should I not use RVM?
I'm new to the ruby language and servers as a whole. I've had some trouble installing using RVM...so I'm inclined to not use it right now, but it seems like it may make installations down the road easier?
I'm interested to hear about your experience with RVM and your thoughts as it pertains to maintaining a server.
RVM is useful even if you don't want to install multiple versions at the same time. I'm a ruby hobbyist (PHP during the day :(), and I have no reason to want to use old versions, but I still use RVM.
Installing ruby is a pain. Getting it from the package manager (at least in ubuntu) gives you an outdated version that changes installation directories from the defaults. I've had nothing but problems with it.
So you think, "I'll just build it from source". Building from source requires getting a load of dependencies and configuring options. Often times I've built ruby only to find out I forgot to enable SSL support or readline support.
RVM takes care of all of this. In 3 or so commands, you have a perfectly built version of ruby.
And I didn't even cover how RVM manages multiple ruby installations for you, which is its killer feature. If you have that need, there is really no other sane solution.
RVM is great as this allows your to install different versions without touching your system's default Ruby install. It is rather similar to virtualenv's in Python.
Another great advantage to having RVM are the gemsets - you can create as many gemsets that are unique to the version, and patch level, of ruby.
I've extolled some of its virtues here and you should also see this blog post.
In terms of maintaining a server - let's take a Passenger install for example; do remember that Passenger is installed as a gem, so with rvm the benefit here is that you can have multiple installs of passenger, tied to a different version of ruby. Of course, typically, you'll have Passenger running on one version at a time, although there are ways to have Passenger, in particular, running on different ruby versions.
I use different Ruby versions for different projects (that's where .rvmrc is really handy). Some deployment environments are happy with 1.9, while there are a couple of legacy servers using 1.8 for some reasons. Also, occasionally I want to launch a specific version of ruby to compare how they work. RVM does all that for me.
When you are first getting used to Ruby, it may not entirely be necessary. That said, what it does is set you up for success in the future. Because once you get hooked, you may end up playing with projects that need to move from, say, MRI 1.8.x to 1.9.x. Or from 1.9.x, to JRuby 1.6.x. My experience is that this happens irregularly, but when it does, there's no substitute for RVM.
Outside of that, the other biggest feature that I use regularly, is the ability to segment one particular release. So I can have an environment for 'stable' gems, and an environment for 'unstable' gems. For instance, while Rails 3.1 has been in release candidate mode, I've had one main workspace for 1.9.2 and a separate space for Rails 3.1.rc? gems on 1.9.2. That makes it possible for me to keep developing my main Rails 3.0 stuff (with one command at the CLI), without having to specify full file paths to the appropriate rails bin files in order to use the older files.
If you're using a Debian based platform where the packagers/policy leads to a really bad default installation you'll have a way better experience using rvm.
I have a bunch of ruby scripts in a folder which is added to $PATH and I think that some of them might be usefult to others. So I want to distribute them and the only 'good' way I know is rubygems (gem containing only binary), it has a very useful advantage of versioning, but also a drawback of initialization time (sometimes it takes some seconds before script starts to run). Are there alternatives?
Gem is good enought for this. I use gem for this purposes as it is very convenient to intall and update.
Gems are built for this. I'm not sure what you think a gem is, but RubyGems is a repository like PEAR for PHP, aptitude for ubuntu, or CPAN for perl, except they contain ruby libraries.
There is no extra overhead or "initialization time" added to your ruby libraries by making them gems. RubyGems simply installs your library - it doesn't do anything else.
Gems are fine for this kind of Ruby script.
To quickly generate a new gem, try out bundle gem.
To quickly distribute gems without using rubygems.org, and in a way that could work for private deployment, check out the idea for microgems.
If you still don't think you need to wrap these in gems, you can simply add the executable bit to your scripts, add shebang lines for ruby, and remove the .rb extension. Then share your script files with whoever wants them.