Comments on: Rubygems Good Practice

By: Matt Mitchell

Matt Mitchell — Wed, 12 Aug 2009 02:54:22 +0000

For the LoadError stuff, how about use Gem.available? instead?

Matt

By: ara.t.howard

ara.t.howard — Sun, 02 Aug 2009 02:48:41 +0000

i think this is a bit pre-mature. specifically i think the approach of pushing gem’s load paths onto $LOAD_PATH is massively flawed and predict it will be removed. i have already had issues with it several times where gem ‘a’ finds a resource erroneously in gem ‘b’s directory. it would be trival (like simply making the gem call take a block – doh!) for rubygems to do a push/pop of the load path during gem loading to provide isolation during loading for guaranteed dependency resolution and i’ve hacked many dep problems into submission be doing precisely this.

if you consider the ramifications (which i think few even understand) that the current gem loading has, which is that:

“requiring dependency ‘A’ means that that client code should then look for each and every other resouce *first* in ‘A’s private lib directory regardless of whether is has anything to do with ‘A’ or not” is just so patently wrong i think it will not stand the test of time — saying that i want to load gem ‘A’ doesn’t mean, to any sane person, that i want to load any other gem/lib i require from gem ‘A’s shit if it happens to provide it.

a larger reason to specify the gem version is that gem authors are bad, really, really bad, at understanding the semantics of version numbers – specifically with regard to interface/implementation issues. i seriously doubt if 1 in 50 ruby developers could explain the ‘1′, ‘4′, and ‘2′ in 1.4.2. rails itself has suffered badly from this – otherwise you’d be working on rails 7.0 or something ;-) github has compounded this issue by forcing developers to bump version numbers to force a gem build without really specifying how or why – just that it should be ‘higher’.

most of the shops i’ve worked at have literally had to re-invent rubygems packaging or a least maintain their own gem servers for just this reason.

i agree with you regarding sane rescuing of LoadError and minimizing over specification of versions though.

By: Deepak Kannan

Deepak Kannan — Fri, 31 Jul 2009 15:47:38 +0000

Why not fail early if rubygems is not there? It will be just another dependency.
Also in ruby1.9 rubygems is built-in right?

If we try to gracefully handle a rubygems error, do i need to know about how ruby gems resolves the dependencies? Although, in my opinion it would be worthwhile to not use rubygems only if it decreases the memory consumption.

i looked at:
http://github.com/fabien/minigems/tree/master
http://rubyforge.org/pipermail/rubygems-developers/2008-July/003988.html

By: Raimonds

Raimonds — Wed, 29 Jul 2009 10:07:17 +0000

Why are you using loading of mocha gem in ActiveSupport TestCase class definition?
http://github.com/rails/rails/commit/7583a24ee0ea85d55a5e235c3082f1b67d3d7694

It seems not according to your recommendation here :)

Because of rescuing of LoadError I several time had difficulties to understand why ActiveRecord unit tests are failing with strange MethodMissing errors.

By: grosser

grosser — Sat, 25 Jul 2009 06:40:23 +0000

I really like this idea, it also enables others to simply use the gem even if they do not seem to have the correct version of another gem installed, or to unpack a gem etc.

By: Tim Carey-Smith

Tim Carey-Smith — Sat, 25 Jul 2009 06:15:59 +0000

One thing to address would be the reason people do the ‘gem “abcd”, “>=1.0.2″‘ in their lib file.

The most common reason is while development, but the way to solve this is to use the gem specification and activate the dependencies in the Rakefile and spec/spec_helper.rb.

Using a Gemfile like in the wycats/bundler and then something like: ‘Gem::Manifest.activate’ would do nicely.

By: Dan DeLeo

Dan DeLeo — Fri, 24 Jul 2009 15:36:48 +0000

There was a rant along these lines some months ago. I gave me one of those *HEADDESK* “OMG you’re right!” type epiphanies and I’ve been doing exactly this ever since. It’s easy. Listen to this man!