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.
Related
I am using a quite recent version of ruby (2.5.1) but some old gems. I am having some issues. I was wondering, is it correct that some gems work only with certain versions of ruby?
If a gem worked with ruby 2.3.0, is it true that it will definitely work with 2.5.1 (i.e. because 2.5.1 > 2.3.0)? Or is that not always the case?
I guess what I'm asking is are newer ruby versions always backwards compatible with older gems?
If a gem worked with ruby 2.3.0, is it true that it will definitely
work with 2.5.1
This is not correct. Programming languages are evolving while growing. This means language maintainers are doing lots of improvements or refactorings that they are new features or removing old components from the language. When the language community announces for new features or removing old feature such as Fixnum in ruby, the developers should follow the instructions and refactor their codebase accordingly. In other words, developers should have a good test coverage to detect any fail and fix it instantly.
In your scenario, as well as I understand you do not have a test coverage. The only but the simple thing should do is just upgrade your gems' versions to latest.
Gem is simply a plug-in library written in Ruby.
Of course, Ruby is developing, new features are appearing, old ones are disappearing.
It's best practice to specify Ruby version in .gemspec file. For example, like this one.
But if not, then you have to manually check the performance. So you can read gem source code or try to use your gem and check it.
For automation, of course, it is best to use tests.
Starting at Ruby 2.1.0 the version policy has been that a change in the MINOR version may introduce API breaking changes.
Should any gem happen to use an API that changes, an incompatibility will arise.
The MINOR version number has changed twice between 2.3.* and 2.5.* so even if a gem happens to have been written in accordance with the documented API, there's no guarantee that it will continue to work unless the gem's maintainer takes the effort to test the gem (and upgrade it if necessary). Automated test suites help a lot.
A standard way to document version compatiblity that is actually tested against is by providing required_ruby_version in .gemspec files.
Interestingly, if a particular gem is really badly written, I imagine it might break even between compatible versions of Ruby. That's not something I've encountered in the Ruby ecosystem but I've made a similar mistake writing Java code (and Java is famous for its backward compatibility) where my own code accidentally used a class that wasn't part of the API. There are many gems. Who knows what's out there? :)
DISCLOSURE: I know very little about Ruby beyond some basic code syntax. Bear with my idiocy.
Ruby 1.8's OpenSSL library doesn't seem to support TLS 1.2. However, there are apps running that are dependent on 1.8, so I want to see if I can run a newer version of Ruby concurrently on the same system and get it set up with newer versions of the same gems.
Currently version 1.8 is at /usr/lib/ruby/1.8. Ideally, I'd like to keep the same structure and install a newer version (not sure what the most recent, stable version is - whether it's 2.3.x or 2.4.x).
That said, I am not a Ruby admin. I inherited a server from someone else who decided Ruby was the best way to do things, despite there being no other Ruby experience within the company, and then they left. I know some system admin stuff, but I don't know:
How backwards-compatible Ruby versions are (e.g. would an app built against 1.8 run without any major modifications on 2.4.1).
How gems work / get updated. Can 2.4.1 use gems from 1.8, or are gems tied to specific Ruby versions? Can there be a mix-and-match? Is there a migration path of some kind?
How to properly manage two different concurrent versions (how to tell an app to use one version over the other, or prevent existing apps from automatically trying to use the new version and breaking if they're not compatible).
Any best install practices (I usually compile from source, but am open to suggestions).
Is it even possible to just update Ruby's OpenSSL library without updating the whole Ruby app? It's currently on OpenSSL 0.9.8o, so it's pretty significantly behind the times.
The server is running Debian 6.0.6 (I'm more familiar with Red Hat and CentOS, though, so any hints on package management, etc... related to this issue would be welcomed).
Modern ruby has "matured" and become very stable. Upgrading from 2.0.0 --> (the latest stable) 2.4.1 is generally quite easy. However, ruby went through a period of fairly major (necessary!) changes from 1.8 --> 1.9 --> 2.0; this part of the upgrade may be problematic.
Gems are installed within the current ruby installation. So for example, you currently have the "ruby 1.8 version" of CanCan. If you update the ruby version of this application, you will need to re-install all gems (presumably via bundle install) for the ruby version. The migration path is basically: Get as comprehensive a test suite as possible; upgrade gems as much as possible within that ruby version; update the ruby version; fix tests and/or code if necessary; repeat.
Use a tool like rvm or rbenv to install multiple concurrent ruby versions on one machine.
See point 3. You probably don't need to compile anything from source.
Ruby 1.8 is old. Support for it was dropped back in 2013. Your application will undoubtedly have a huge list of outdated libraries now, with all sorts of security vulnerabilities -- that's what happens when you don't update it for 6+ years! From a security standpoint, I would not suggest trying to find some workaround for this one OpenSSL issue and ignore the larger problem here.
I'm new to running a Linux server and slowly getting up to speed with things.
I have already installed nginx via the apt-get function, although I'm following a tutorial which recommends installing it as a ruby gem instead.
Is there any difference in the functionality/limitations to installing it as a gem than by using apt-get? - I'm worried that it won't work for non-ruby applications if it is gem installed?
Is there any difference in the functionality/limitations to installing it as a gem than by using apt-get? - I'm worried that it won't work for non-ruby applications if it is gem installed?
There aren't any limitations on the version of Nginx that Passenger installs for you. You should be able to use it with other languages as you normally would (providing you know how to configure Nginx.) I was able to use it to connect to both Ruby and Node.js sites with no problems.
The people at Phusion have a nice page explaining why they are forced to provide their own version of Nginx (rather than using the standalone one) and it comes down to the fact that Nginx does not allow to be extended at runtime. Extensions like Passenger must be compiled into it. See this page for more information on it: https://github.com/phusion/passenger/wiki/Why-can%27t-Phusion-Passenger-extend-my-existing-Nginx%3F
(Note: When I tested this I used the installation instructions from the Phusion web site https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#install_on_debian_ubuntu , rather than the gem that is indicated in your tutorial, but I suspect they are both equivalent.)
I have run into this too. Where I am recommended to use one package manager over the other. I would question the age of the tutorial first, if it is not relatively recent you may want to consider if the information is no longer up to date. The libraries installed with that method may not be up to date.
However, if you intend to follow through with the tutorial you may end up needing it installed as the tutorial describes.
The difference is that one may not have all the libraries that are required or may not have the most up to date version. One tool could be buggy, I don't think this is the case in your situation but it is in Macports v.s Homebrew in my opinion. It might install to a different directory based on what install method you use, if you use a method off the web and then go back to the tutorial it could be installed to a different location then your tutorial expects.
If you have to follow the tutorial then I would all the way through, but if you don't need to use the preferred method that the program/library maintainers recommend. If the tutorial is out of date you could try to find an up to date tutorial.
good luck!
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am new to Ruby and trying to wrap my head around following concepts: bundler vs RVM vs gems vs RubyGems vs gemsets vs system rub and I'm confused.
Can someone please describe a 'best practice' of how I should manage all this on a fresh install of the latest version of Ubuntu? What should I install, and how should I use it all?
I'm guessing that doing a sudo apt-get install ruby is not be recommended, but I am not sure. I tried it on my system in addition to 'all the other Ruby stuff'. It's just adding to my confusion. I am not talking about Rails but just regular Ruby gems (e.g. Vagrant, Chef, scripts).
As per the previous answer, this is quite a lot to cover, so consider this a short introduction.
gems are the way Ruby libraries are packaged. They are to Ruby what jars are to Java. Inside a gem file, you find Ruby code (.rb files), but also tests, and a special file giving information on the gem itself, such as its name, dependencies and version (gemspec). Any Ruby project can define the gems it needs via a Gemfile that just need to declare dependencies. Rubygems is the name of the package manager - the tool used to install the packages (while the gems are the packages themselves). Rubygems is now part of Ruby.
Bundler is what makes managing gems bearable. Based on your Gemfile, a simple call to bundler using bundle install will download and install all the required gems. Using standard gem command, you would have to install each of them manually, using gem install <gem_name>. Bundler is not part of Ruby (it is itself packaged as a gem), but it a "de facto standard" for most applications (you will not find many people not using it, and no good reasons not to use it, actually).
RVM is a tool allowing you to install multiple versions of Ruby on a machine, switching between them when needed. This can be used to install both a Ruby 1.8 and 1.9, or even a "MRI" (Matz's Ruby, the default implementation) and alternatives (such as JRuby or Rubinius). Note that RVM is not alone in this field, see for instance rbenv.
A gemset in RVM is a set of gems specific to a given context, typically a project. This is useful if you are for example developing different applications, each with its own sets of gems, and want to keep them separate.
system Ruby is, when using RVM, the Ruby version installed on the machine (ie, not via RVM).
If you are just starting, gems and bundler are of interest to you. You can let RVM and gemsets aside for now.
You're asking for more information in one question than is in-scope for Stack Overflow. To cover it all would take a book.
On Ubuntu it's easy to install and remove gems to the "system" version of Ruby, so get used to installing and removing regular gems via sudo. (On Mac OS I'd give different advice because Apple bundles Ruby for their own use and it's not a great idea to mess with it.) Then, when you have an idea how the whole gem idea works, and you know you want multiple Ruby versions on your system, try "rbenv" or "RVM" and install a version or two in your sandbox.
Linux makes it easy to add/remove Ruby via a distribution, but we're limited to the versions the distro maintainers have packaged, so I usually install from source. But, that's a pain when managing several versions of Ruby for development, test and production systems, which is why rbenv and RVM were invented -- they handle the dirty detail allowing us to concentrate on programming.
I've used both rbenv and RVM, and have been using rbenv for the last six months or so, with good results. It's less complicated than RVM which I like. In either case they make it easy to have different versions installed, with separate sets of Gems. You can have different Ruby versions open in different terminal windows if you want, making it easy to test for compatibility.
Rule one when debugging is to make changes one at a time, which is true for learning to program or learning a new language. Don't be distracted, just keep it simple.