[Rubygems-developers] Another plug for Simon's patch

Mauricio Fernández batsman.geo at yahoo.com
Thu Apr 1 10:05:37 EST 2004

On Wed, Mar 31, 2004 at 10:59:25AM -0500, Chad Fowler wrote:
> >IMHO Simon's patch is dangerous (sorry Simon ;) for the following
> >reasons:
> > * installation and loading of gems are separate in rubygems
> Are you suggesting that they shouldn't be separate?

Only that this issue wouldn't happen if installation and loading didn't
behave differently in the sense that you can install many versions at a
time but only one can be loaded, which can't be changed because there's
no way to 'unrequire'. (If you converge the other way around and allow
only one version to be installed, you're essentially doing versioned
releases of the gem repository, which you don't really want to do.)

> > * you can have more than one version of a lib installed
> > * require_gem (and require) defaults to the latest installed version
> >
> >That is, IMHO require_gem 'log4r' is evil because it doesn't isolate
> >the lib from future changes in the API of log4r. Note that having the
> >right version installed is not enough, you have moreover to be careful
> >*not to install* a later, incompatible version; this can be tricky 
> >since
> >the new version could be required by some other gem.
> >
> "evil", I suppose, means "horrible"?  I think it comes down to how 

'evil' as in 'introduces potential breakage w/o warning'.

> careful you want to be and how stable the libraries you depend on tend 
> to be.  Also, look at the current non-rubygems scenario: require 
> 'log4r' is going to result in broken code if you install a later, 

* currently, installing a new version is a deliberate action. OTOH, in
  rubygems the newer version might get installed because another
  unrelated gem depends on it. This means you might break both other
  gems and local scripts w/o any warning.
* there's no reason why gems should have the same shortcomings the
  current 'manual installation' has. rubygems already allows several
  versions of a lib to be installed, IMHO it should also guarantee that
  they will actually work, and that installing a gem won't result in
  half of your other gems failing.

> incompatible version.  With RubyGems, if this breaks, you go into your 
> code and change one line, requiring "<= broken.version".  That seems 
> considerably less "evil" than the current "require" in this context.

I still think require_gem ">1.0" is more evil than the current require
for the following reason: it bites sneakily :-P Installing a gem can
trigger several more installations, which doesn't happen when one does
make {config,setup,install}. Installing a single gem could result in a
cascading effect that could change a number of critical gems, required
by several others, and break a big part of your installation.
Also, changing one line in all (or a substancial amount of) the installed
gems can be quite a PITA. And you'd have to do it for each version you
install unless whoever's making the gem realizes he must add a "<2.0"
to the gemspec.

> >If rubygems doesn't guarantee that the right one will be used, in
> >practice you cannot install several versions of a library, unless they
> >are compatible (in which case there's little merit in keeping an older
> >one).
> >
> I don't feel that you have fully demonstrated this assertion here.   At 

We agree on the fact that installing a gem can break your local
scripts/other gems, right? Then I guess we just have different views on
how bad requiring the user to add "<2.0" is. My feeling is that it's
hardly acceptable, for that's something I'd expect the package
management system to take care of for me, and the problem could involve
changing *lots* of installed gems/scripts. In addition to that, it might
not always be obvious that the problem is an incompatible API (and which
one?), esp. if the breakage is only discovered later.

> any rate, actual "in practice" reports will help us sort this out.  
> That's the reason for Alpha releases, right? :)  We can sort all of 
> this out before RubyGems reaches a final release by listening to real 
> experience reports from the community.

There's no need to let beta-testers bang their heads on a wall if we
can remove the wall :)

In addition, I wouldn't expect this issue to be noticed until
* there's a substantial amount of gems with dependencies
* some of the libs depended on face an incompatible API change

i.e., *not* during the alpha-beta phase. 

At that point, this could bite rubygems users and there wouldn't be any
easy solution. IMHO it's better to prevent this than to let it happen
and ask people making gems to fix it afterwards.

> >I believe
> > require_gem 'log4r'
> >should be
> > require_gem 'log4r', ">1.0.5" # implicit < 2.0 and assumes a 
> >versioning
> >                               # policy
> >
> I understand the potential need for multiple relational requirements, 
> but I personally hate the implicit "< 2.0" idea here.  I would be more 
> accepting of the more verbose:
>    require_gem "log4r", "> 1.0.5", "< 2.0.0"

You still have the following problem: how does the 'gem-maker' know which
version to put in the "< ..." part? I believe the best way is making
sure everybody follows a consistent naming policy (that's why I said in
my other posting on lib. versioning that IMHO that policy should be
documented in the gem developer's manual). But if the policy is always
followed (and we'd better encourage that, for the sake of the end-user
experience) the "< 2.0.0" is redundant. Another way to view that is that 
the implicit "<2.0" encourages people to comply with the minimal policy
required to make the system work well.

Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

And Bruce is effectively building BruceIX
	-- Alan Cox

More information about the Rubygems-developers mailing list