Local gem install vs running setup.rb - ruby

What is the difference between a ruby library installed from a tarball versus through a gem install?
My machine can't connect to rubygems.org because of a university proxy, so all my installations happen locally. I have some gems that I've installed using a gem local install, and others where I've downloaded a tarball and run setup.rb or some such. In my newbie-ish state when messing around with Ruby I wasn't too phased about this inconsistency, but it bothers me now.
I assume rubygems is the preferred method, but I'd like to understand the exact pitfalls so that I can know what to watch out for when I try clean out my machine.

The most important difference is that Ruby extensions installed without the gem mechanism cannot be easily uninstalled or updated (except they provide their own mechanism for that). Automatic installation of dependencies is also largely simplified with gems.
If you are behind a proxy, you can tell gem to use that proxy as well, e.g.
gem install foo --http-proxy http://192.168.0.1:81
or define the environment variable HTTP_PROXY like
export HTTP_PROXY=http://192.168.0.1:81
Look into your browser/network settings to find the proxy address.

Related

Is it recomment to install ruby dependencies into local folder?

I'm learning ruby recently and I'm a front-end developer, I found the dependecies are installed to C:/Ruby31-x64/lib/ruby/gems/3.1.0 folder when I use bundle install. it seems dependencies are installed globally by default like the npm install -g. I know that Bundler also have a way to install the gems to the local folder, so I wonder is
it recommend to install the dependencies to the local folder like npm does?
Similar to Composer, Bundler takes care of maintaining your dependencies, but rather than installing everything in the project folder, it distributes your gems system-wide, which are then shared by all of your projects. Using the Gemfile in your project folder, it keeps track of which libraries each project needs. Bundler is the default package manager for Rails, so you should simply let it do its thing. It does it quite well.
Hope this helps.
Use a Version Manager for Ruby, and Bundler for Gem Version Management
There are occasionally reasons to install gems in from one another isolation, but most often you should use a Ruby version manager to manage your non-system Rubies and Bundler to handle multiple gem versions and locations. Avoid modifying your system Ruby or its gems whenever possible. Also, be aware that even using RVM gemsets (or similar features in other version managers) without tweaking some poorly documented features like rvm gemset globalcache enable can create a level of isolation that is likely unnecessary and can bloat disk usage dramatically.
If You Need Gem Isolation...
That said, if you want to ensure you are isolating your gems or localizing them to your application and aren't using direnv's Ruby layout to manage all the various environment variables involved, you can use Bundler's BUNDLE_PATH environment variable to "vendor" your gems into the local application directory (these days usually under vendor/bundle). For deployments or containerization, you can also invoke bundle-install with the --deployment or --standalone flags and a list of gem groups to install if you don't want to rely on the availability of Bundler itself after installing the gems.
This sort of thing might be useful for building containers or tarballs, but isn't really very useful for development. Don't do it unless you have a really strong reason.

Ruby: CLI script failing when requiring gems installed through git

I am patching a script, and want to run code from a repo I manage that has patches.
The gem in question is not installed through a published gem but through a github link
When requiring any gem that is normally installed. The script works. But requiring any gem that is installed through a github link fails. Any suggestions?
If I understand the problem correctly, there are a few solutions:
Clone the gem that's only available via the github link, build the gem locally, install it. You should be able to require it
You might be able to manage the project with bundler and a Gemfile. Instructions here for the syntax. Bundler basically does what I suggested above, for you. I don't think gem can install a gem from a remote natively?
Would love to see some more clarification, and if you're using a Gemfile the relevant snippets
So the issue was I was running the script in question using ./bin/path/script
This will not work if the script includes github referenced gems, you need to prefix this with bundle exec which is not immediately obvious, given that when you use non-github referenced gems, it works fine without it.
Now running bundle exec ./bin/path/script will work for both, it's probably just better using that wherever possible.

How to install a gem so that it executes independent of currently active RVM gemset?

I am writing a dev command-line tool gem (let's say called "tool") which I would like to use in any place in the system. I use RVM for different projects, but this tool should be available from the command-line inside those projects.
If I simply install the gem globally using "gem install" (let's say it installs to /usr/local/bin/tool), the executable is of course available inside of other projects, but since the gemset changed when executing "tool" it fails saying that it cannot find the "tool" gem (because "tool" was never installed to that gemset). I don't want to add the gem to all the Gemfiles of all the projects.
What's the best way of dealing with this? Perhaps there is a way to "lock" the gem_path/gem_home in the executable at the time of installation?
It turned out that https://github.com/sportngin/brew-gem does what I want, installing a Rubygems gem via brew and locking its GEM_HOME and GEM_PATH in a bin wrapper it generates, so that everything works even when executed in the context of a different RVM gemset.
I forked it into https://github.com/gtmax/brew-gem, adding support for installing a brew gem from a local.gem file or from a gem project on github.

Ruby command line tool crash when switch ruby version in rvm

I am trying to make an CLI tool with ruby.
My tool require some library in bundle (log4r, ...). So problem appear when i switch my ruby version (2.0.0 -> 2.1.2) or when switch gemset, some gem are not install in new ruby environment.
So how can i make my app work like vagrant, which work in every version of ruby i am using?
If you package your application as a Gem, you can include a Gemspec that describes your application. One of the things you can specify is its runtime dependencies; when the user runs gem install myapp, then the gem command will make sure it includes everything you specified (like log4r).
It will be harder to make this happen without Rubygems. You can package your application along with a defined version of Ruby and all its requirements - that's what Vagrant does - but that makes your application a larger download and means you have more to maintain. It's going to be hard work if you want to install your app system-wide and have it work with every single Ruby environment. It's far better to let the gem application install your app (whether systemwide, or via rbenv/rvm) and let that manage your dependencies for you. There's the default gems plugin for rbenv and rvm gemsets to help manage this.

What is the difference between installing Rubygems "locally" and "system wide"?

I am running RHEL 6.2 on a VM (I have no control over it). I would like to use Ruby along with Mysql to do the work I need to do. But right now the server does not have the mysql gem installed. It doesn't even have ruby gems installed. So I can't simply do gem install mysql. The people maintaining the server suggested I do local install of ruby gems. Is there a benefit to this? What if the server is hosting a web application that consists of code depending on a gem? Will this effect anything?
Either in ~/.gem (local) or in /usr/lib/ruby (system). Locally installed gems are accessible by you only, system gems everyone can use.

Resources