tags:

views:

216

answers:

3

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.

+1  A: 

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]

SeanJA
+1  A: 

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.

Mike Woodhouse
A: 

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.

Ethan