I'm confused about the world of Ruby Gems. There are several well-known repositories. Which is the right one, or does it matter?
I guess Gemcutter is the hip repository right now. They definitely have the nicest-looking website. Does that mean I should get my gems from there?
The main reason I'm asking is that I want to make sure I'm getting the latest release of the gem. If I don't specify the source, am I in danger of installing a crap version of the gem, or am I bugging?
Why is there more than one repository anyway?
GitHub gem building is defunct -- it got disabled for an upgrade, and was never re-enabled because GemCutter is taking over that role. There are no new gems being generated on GitHub.
RubyForge is planning to phase phase out gem hosting too -- GemCutter will become the standard source for gems.
Edit: The whole migration plan is here
Go gemcutter. It's been publicized that gemcutter is going to become the new de facto. But, if you can't find the gem on gemcutter, you have to look at github or rubyforge. Hopefully most people will (if they haven't already) start moving towards gemcutter.
I think that's where "we" are at right now.
Why is there more than one repository anyway?
Because you can run your very own gem server and install from that (some folks use it on large deployments to host their own gems).
Related
..vs just listing gems used for the gem development in Gemfile (while everyone uses bundler anyway)..
..except for giving your fingers extra work?
It's not clear there is any.
In theory, RubyGems has the information necessary to run tests with add_development_dependency and test_files (see this question).
Some believe that this should be outside the scope of RubyGems (see this huge thread).
In practice, there is currently no real advantage, and the fact that RubyGems still installs test files by default is a drawback, as might be the lack of flexibility that Gemfile offers.
One benefit of add_development_dependency is that if you publish your Gem to rubygems.org, those dependencies can be listed on the gem's details page. Thus if anyone finds your gem via rubygems.org, they have an idea right away what will be required if they want to contribute to the gem.
My Rails site uses a certain gem which is really not very good. Every time I need to do something new I end up having to spend as much time adding features to the gem as I do adding code to the actual Rails project. But I don't mind, and I have my Gemfile set up to point to my GitHub fork of the gem (I tried submitting PRs, but the maintainer seems to have stepped down).
The problem is that I really haven't found a sane way of testing new things I add to the gem. It'd be especially nice to test it within rails c, but the only ways I can think of doing that are a) Changing ~/.rvm/gems/.../foo.rb, which doesn't seem right or b) Bumping the version, pushing to Github, and running bundle up, which in addition to being time-consuming is obviously a disaster since I don't know for sure whether the commits I make are right or not.
I'd even be perfectly happy with a standard irb. But various permutations of require lib/foo from within the gem's directory don't work.
So what's the best practice here?
If you are using a gem and working on it at the same time, the best way is to use Bundler and provide a local path:
gem 'my_bad_gem', path: '../my_bad_gem/'
This will look for the gem under the given (relative in this case) path. Another option is to use local git repositories (see http://bundler.io/v1.3/git.html).
I want to install a gem via gem install, but I need it to resolve with dependencies of the current project.
Basically I want the functionality that bundler gives me when I specify gem 'xyz' in a Gemfile, but I don't want to add that specific gem into the Gemfile.
I tried doing bundle exec gem install ... but it doesn't seem to work.
edit: The reason why I don't want to add it to the Gemfile is that it might be something like metric_fu, metrical, saikuro, rails_best_practices, etc. Simply gems that are kind of utility use and might only cluttler the project.
I might only want to use them temporarily, or install them, try out, if it doesn't work out the way I want do rvm gemset empty and bundle install again to clean up.
The point of Bundler is, in part, to prevent you from doing things like that (to prevent you from injecting gems from outside when your project doesn't declare them).
Looking for a way of doing that is looking for a bug in Bundler. If you did manage to find some way of skirting Bundler's enforcement mechanisms, you should probably not use it; instead, you may consider filing it as a bug with Bundler's issue tracker.
Now we come to the real questions: what can you do? and what should you do?
You should use either RVM gemsets or Bundler to isolate your application and its gem dependencies. You don't need both. I would recommend Bundler for this purpose over RVM gemsets.
You should add to your Gemfile any gems that you want to use and that integrate with your application (i.e., that either load your application or that are loaded as part of your application). This is not a requirement for any gems that refrain from integrating with your application.
You should refrain from committing a changed Gemfile or Gemfile.lock to version control until you are satisfied that your application continues to operate acceptably (tests pass, new gem does something useful, etc.).
Or you should stop using Bundler, because you want to do things it is explicitly designed to prevent you from doing (not recommended).
At the risk of sounding dumb, why not add it to the gemfile? You can always add it to its own group if you don't want to have to install it everywhere.
A slightly different approach is, if you're using version control, such as Git, to create a new branch and install the gems. If it doesn't work out, uninstall the gem (I'm not sure this will be done by bundle update on the old branch) and trash the branch. If it does, work, merge your stuff into the old the branch.
Though I do believe the other answers and comments have some very good points.
I'm really just a beginner to ruby, so hopefully this is an easy one. I've got to the point where I'm starting to look into some of the gems that the community have put together. I decided to check out something that would help my application consume rss feeds. So, headed over to rubygems (which is where i thought people go to get these kinds of things) and searched for rss. I found this one;
http://rubygems.org/gems/simple-rss
instructions were to just install the gem with
gem install simple-rss
So far, so good. When i came to actually use the gem, the documentation I received from doing the above was a bit naff, so i searched a bit further and found the git repo;
https://github.com/cardmagic/simple-rss
The documentation there (their code examples) complain about missing methods etc. and after a bit of digging I came to the conclusion that I must have downloaded an older version of the gem than the git trunk.
So, my question is, should I be using rubygems to get the latest gems, and if not, what other resources are out there to help find the latest builds of the comminities gems?
As far as finding a good gem for a task — use Ruby Toolbox, since it also shows you how actively maintained a gem is. Here's, for example, a section on feed parsing.
If you want to get the latest gem code that hasn't been released yet, you could download the code directly from github and build the gem yourself. However, it's easier to use bundler for that. It allows you to create a Gemfile for your project looking something like the following.
gem 'simple_rss', :git => "git://github.com/cardmagic/simple-rss.git"
Then run bundle command to download and build these gems from their corresponding sources.
In general, bundler is a great solution for managing gem dependencies for any ruby project. It provides ways to quickly reference any released gems, automatically builds gems directly from a git source, git refs, or paths on your filesystem, and has other convenient features.
By far the best place for all things Ruby & Ruby on Rails for the devs is the Ruby Toolbox
It seems like there are no guidelines on Ruby Gem package submission. There's no way to tell what is the definitive package for your needs. At least not within the Gem framework itself. Or am I missing something?
For example: I found out about "ActiveLDAP". I did
gem search ldap --remote
and got back
*** REMOTE GEMS ***
activeldap (1.0.2)
ambitious-activeldap (0.1.1)
ruby-activeldap (0.8.3.1)
ruby-activeldap-debug (0.7.4)
I ended up installing 'activeldap' and 'ruby-activeldap'. Turns out they're the same package: "ruby-activeldap" is just an older version.
Is there a way within the Gems framework to differentiate them, without having to Google for the answer. A short doc string, for example, or a dependency tree?
Seems like there are lots of these type of discrepancies in Gems.
If you are installing the gem because of a dependency in a script, you might be able to tell based on:
require_gem 'rake', '>=0.7.0', '<0.9.0'
Other than that, I am not sure either to be completely honest. I would usually go with the latest version of something in cases where a require does not specify which one is needed.
[edit]
I would use the one that appears to be the most mature first (1.0 over 0.X).
[/edit]
I think you could look around and find guidelines, but whether or not they're followed is an entirely different matter!
This is open source software - it costs you nothing to buy, but I'm afraid you're going to have to invest some time to determine if a package does what you want.
It's relatively straightforward to determine how recently a gem has been released and how many times and with what frequency updates have occurred. These are indicators that the source is being actively maintained and that effort is going into its continuing relevance. You can also look at tests (usually installed with the package), existence of bug tracking facilities, discussion groups or forums and the like in order to assess the degree of commitment from the developer(s) and the amount of penetration and community around the code.
Beyond that, what were you hoping for? Value for money? Some central authority that accredits the fitness for purpose of a library? It ain't going to happen any time soon, and that's probably, on balance, no bad thing.
You can get more detail in your search results that might help you narrow it down if you use the details and all options:
gem search activeldap --remote --details --all
all shows the list of versions.
Part of the output:
activeldap (1.0.2, 1.0.1, 1.0.0, 0.10.0, 0.9.0)
Authors: Will Drewry, Kouhei Sutou
Rubyforge: http://rubyforge.org/projects/ruby-activeldap
Homepage: http://rubyforge.org/projects/ruby-activeldap/
Ruby/ActiveLdap is a object-oriented API to LDAP
ambitious-activeldap (0.1.1, 0.1.0)
Author: Matthew King
Rubyforge: http://rubyforge.org/projects/ambition
Homepage: http://ambition.rubyforge.org/
An ambitious adapter for ActiveLDAP
Beyond that, as Mike said, it's sort of a matter of poking around on the Web to try to suss out what's the most relevant version.
One thing to note: wholesale migration around mid 2007 in the Ruby/Rails communities to Github. So if you find something but it's not on Github, make sure it's not some old version that's been superseded.