Why RVM requires YAML? - ruby-on-rails

While installing RVM from, it is suggested to provide YAML source tar as well.
Don't know why YAML is needed by RVM? ( link :-https://github.com/rvm/rvm-site/blob/master/content/rvm/offline.md)
We can very well install it as a separate gem , right?
Please provide your insights.

YAML is part of Ruby's standard library and is thus shipped with Ruby itself. In order to compile Ruby with YAML support, you thus need libyaml installed. Since YAML is quite popular in Ruby and is e.g. used to specify all the metadata in packaged Rubygems, a Ruby without YAML is not very useful nowadays.
Now, some time ago, there was a pretty nasty bug in libyaml (the library used by Ruby to parse and generate YAML). In versions <= 0.1.4, it was possible to execute arbitrary code by making the ruby process parse a specially crafted yaml source.
Because of this, RVM usually downloads and compiles an up-to-date version of libyaml to ensure the compiles Rubies are safe from this vulnerability.

Related

How is jekyll related to ruby?

I have a pretty general question regarding Jekyll. When I try to install it on my mac I get an error saying I don't have write permissions to the ruby directory. After looking around online I've found that you can fix this by installing a ruby version manager. My question is why does this work? Is Jekyll essentially an extended version of Ruby? How are they related architecturally?
Thanks!
I think Jekyll is a Ruby Gem. So that would mean it is written in Ruby, and needs the Ruby interpreter on your system to install/run it.
RVM is just a tool to help you manage your different Ruby versions (because you could potentially install multiple versions at the same time, for different users for example).
Jekyll is built in Ruby and is available as rubygem. That's why it requires Ruby to build. It provides command line interface to carry out deploy and other operations and provides minimalistic HTTP server.
It is also equipped to convert markdown to HTML using redcarpet ruby gem.
It's AWESOME.

Updating Ruby 1.9.3 -> 2.0.0 without losing gems

Have had 1.9.3p194 (RubyInstaller) with Ruby on Rails and all kinds of Gems installed on my WinXP. Now I want to update the whole setup.
Updating RoR (to 4.0.0) and gems was easy: gem update rails, gem update --system, gem update.
But how do I do that with Ruby? Is there an easy way to update the installation?
If not, and I have to install the fresh package, then how do I do it with little hassle?
I have downloaded the fresh 2.0 RubyInstaller. I have read that I shouldn't install this new Ruby version in the same directory as my old Ruby version (c:\programs\Ruby) that's why I chose a c:\programs\Ruby200 directory. During the installation I clicked on every additional setting, including the "include new directory in the PATH variable" type of choice. But now when I type ruby -v I still get 1.9.3p194 and the new directory is absent from PATH (I haven't rebooted, so maybe this has something to do with it).
So how should I really install the new version? Should I simply change the old PATH to the new one? Or should I instead only add the new one without removing the old path (so there will be some kind of advantage of having both 1.9.3 and 2.0)? Or should I simply delete both installations and install 2.0 from the start?
How do I easily transfer the gems (or the list of them, so the gem update could handle the installation/updating) from my old installation to the new one?
I am using JetBrains RubyMine 5.4 editor, and would like to know if I need to do something there as well (for both the new and the existing projects).
Like many POSIX users, I rely on rvm and bundler to manage ruby versions & gemsets. Unfortunately, rvm is not available on windows. Although I haven't tried it personally, it looks like pik is a viable windows alternative. I would recommend checking that out.
You should also definitely look into bundler if you're not already using it; since bundler is just a gem, it should be platform independent.

What do rvm and rbenv do under the hood to install Ruby? [duplicate]

This question already has answers here:
How do RVM and rbenv actually work?
(5 answers)
Closed 6 years ago.
For years, I've been dreaming about learning Ruby and the Rails framework. (Most of my development career has left me too busy to devote time to picking up a new language properly, but I'm making more time now.) I like the notion of being able to work with Ruby to develop quickly, but I'm having trouble understanding the Ruby installation process.
Each time I've encountered it, the Ruby installation process varies slightly. The two laptops I've used over the past several years have usually been running a then-recently released version of OS X, and all seem to ship with Ruby 1.8.7. Any modern version of Rails requires Ruby 1.9.x. So, I search the web and invariable bump into a post like this:
Use this awesome tool called rvm to manage multiple Ruby installs on the same machine.
or this:
rbenv is fantastic, and lightweight compared to rvm, use it instead.
Really? What is the Ruby install process doing, and why is it so complicated? By now I've gotten Ruby installed and running, but it seems like I've always had trouble with it. I'm genuinely confused and want to understand how Ruby lives on my system. What files are these configuration tools manipulating, and why can't I just do it by hand?
To put this a little differently: If I was RVM or rbevn, what steps am I taking to make Ruby work on a given system? Am I manipulating configuration files? Am I downloading source code and compiling it into an interpreter? Am I downloading a precompiled interpreter?
Rbenv and rvm manages multiple versions of Ruby. The question you link to describes how both of those tools do that (some people are of the opinion that rvm's integration with your shell is too heavyweight/magical ) . The ability to have multiple versions of Ruby coexisting nicely is a pretty big win. Historically there have been some disruptive releases (eg 1.8.7, 1.9.2) and so being able to migrate your development piecemeal or easily work on legacy projects has been very advantageous.
The Ruby install process isn't that complicated at its heart - it's pretty much the usual download the source ./configure && make && sudo make install (RVM also has support for prebuilt Rubies). You can however tie yourself in knots (especially as a newcomer to Ruby)
While some missing dependencies will just cause the Ruby build process to fail, others will just stop specific Ruby extensions from compiling (openssl or readline). You think you have a fully functioning Ruby until you try to run some code that uses those extensions. Others are even more subtle, for example if libyaml is not available then some versions of Ruby fall back to using syck as the YAML library instead of the more modern psych, with subtle differences.
RVM just makes it very easy, compiling nearly any Ruby interpreter, version or patch level (jRuby, Rubinius, MRI etc.), with or without extra patches is only ever a single invocation. It's not doing anything very magical but it does remove a lot of friction.

Trouble understanding RVM, gems, and general Ruby on Rails environment setup

I've read through a few Q&A's here on this subject, but am still confused. I'm new to linux and new to programming, so please keep that in mind.
I understand that Ruby Gems is similar to apt-get. It's a package manager -- correct?
So if I want to install or remove gems, I can do it via a command like: sudo gems install {gem name}
So what then is RVM? Why would I want to use it? Doesn't Ruby Gems do what RVM does? Why then does Ruby Gems get installed with RVM?
Also, when specifying gems in a project's Gemfile, then using bundler to update, etc.. is this downloading the gems only to that project, or will they now be available across all projects?
Also, what is $PATH about? I don't know much about it, so when I read about it, I'm confused about what is the right $PATH, what if anything I should do to manage references in $PATH, etc. Can someone explain or point to any resources for beginners?
And finally, I'm using various tutorials, and they differ on versions for everything from Ruby to Rails to Gems. a) Should I be modifying my environment to match the version that they use? b) Once I'm done with a tutorial, should I leave all the versions alone, or should I try to upgrade everything up to the latest and greatest?
It's confusing because if I leave everything at the version levels in the tutorials, then I feel like I'm stuck in the past. While if I upgrade to the latest and greatest, I feel like things have all switched around on me and I'm not sure how to use all the tips and tricks I learned.
Thank you in advance for taking the time to help. Cheers.
This question is very broad so I chose to try to balance the explicitness with conciseness. If anyone finds anything wrong with the answer please tell and I'll straight up own up to it :)
RVM is a Ruby Version Manager. Hypothetically, some projects might require you to run ruby 1.9, another legacy project might require 1.8. RVM allows you to have both installations installed side-by-side, as opposed to having one authoritative system-level version of ruby. This facilitates installing later versions of ruby without fear of breaking anything, or of meddling with other user accounts' ruby version requirements (since usually one installs RVM at the user level, in your home directory). This even lets you try out the bleeding edge version of ruby without having anything to worry about, since you can always switch back easily.
When you install a gem, it generally becomes available to you everywhere that ruby installation is available to you, so in any project. When you specify gems in your Gemfile you're basically saying that independently of whatever gems you may have installed and their versions, that project requires gem x of version 2.2, y of version 3.1, and z of version 1.1. If you didn't already have those gems it installs them, if you did but not those versions, it installs them.
Path is an environment variable that allows operating systems to know where to look for programs when you invoke them. If you type someapp in the terminal, how can the operating system possibly know where someapp is? Well it searches for it in any of those directories supplied in $PATH. You can see what's in your path by doing echo $PATH in the shell.
As for varying versions of ruby, this brings me back to the reason for RVM. You can if you want install the version of ruby they use, and then in your Gemfile specifically state the version of the gems the tutorials use and you should be fine. You can have different versions of gems installed, and you can have different versions of ruby installed thanks to RVM.
Personally I would recommend working towards the latest version of everything so that it remains relevant. For example, it would be counterproductive to work on a tutorial that uses Rails 2 since it changed a lot when it went to 3, and somewhat from 3 to 3.1 and above etc. If possible use the latest versions, or at least be aware of the nuances (the base material tends to stay more or less the same), lest you work on a tutorial that is older only to get to work on your own project with the latest version of everything and not have it work.
Simple solution to your dilemma: ditch the tutorials that are too old. There are tons of resources out there that you're bound to find up-to-date material. Worst case, dated material typically has community support in form of comments which state the changes between the dated version of something and its corresponding recent version. E.g. "keep in mind that haha.what changed to lol.wut in version 3.1"
I can understand that this is confusing, RubyGems are as you write a package manager. RVM is a tool that makes it possible to have several versions of ruby installed on your system and easy swift between them.
If you using various tutorials, and they differ on versions for everything from Ruby to Rails to Gems you can (if you want to) create a RVM Gemset for the version you use. You will then create a sandbox for the Gems Bundler use in your project.
Bundler are as you write a tool for manage the Gems your application depends on. In the old days before Bundler it could be a hassle to figure out which gems your application depended on. Now Bundler do this for you.
Both Bundler and RVM are tools that is not absolutly necessary to use but they will help you. I personally do not use RVM anymore. It is to much of a monster in my taste so I use rbenv instead.
Regarding what versions of Rails to use I do agree that you should try to use 3.1 versions if possible but if you find some example application using Rails 3.0 you do not need to upgrade it. Also you do not need to run the absolute latest version of Rails. Rails 3.1 have a lot of bug fixes that the latest Rails 3.1.3 might not have.

Upgrading Ruby 1.86 to 1.9 by overwriting binaries

I used the one-click installer to install 1.86 a while back.
I wanted to upgrade to 1.9 but since there's no one-click installer for 1.9 I just downloaded the 1.91 binary and overwrote my 1.86 install.
Didn't work so well. I got errors all over the place afterwards.
What's the proper way to upgrade (for a dummy, i.e. me)?
The downloads page has three options for Windows:
* Ruby 1.8.6 One-Click Installer (md5: 00540689d1039964bc8d844b2b0c7db6) Stable version (recommended)
* Ruby 1.8.7-p72 Binary (md5: d4b04ba03a76dc70120fe96ffa22e5df) Stable version (recommended)
* Ruby 1.9.1-p0 Binary (md5: 921db53c709ce20106610f7d229e24e1) Stable version (recommended)
Normally should it be ok to install 1.86 with the one-click installer and then overwrite the install directory with 1.9? Or should I not have done that?
Is there a better way to do a clean install of 1.9?
I guess I'm just not sure how to install 1.9 without using the 1.86 one-click installer first.
To install, just extract the zip file into a folder of your choice. You will find that it gives you a folder structure roughly equivalent to what you see with in your 1.8 install folder. Scite and the Samples are missing, and of course you won't have your Start menu shortcuts.
I would recommend that you install Ruby 1.9 into a folder separate from your 1.8 install, then change your path statement to point to this new folder.
What is likely happening is that you are pulling in gems or other code that is incompatible with 1.9. A fresh 1.9 install will give you a better idea as to what code is missing and/or needs to be updated to work.
--Bruce
Ruby 1.9 probably installed just fine, but last time I heard 1.9 is still not 100% compatbile with Rails, although the very basics are meant to work. Are you aware of this being the case?

Resources