[Rubygems-developers] PATCH: respect requirements of gems

Dick Davies rasputnik at hellooperator.net
Thu Apr 22 16:00:06 EDT 2004

* Mauricio Fern?ndez <batsman.geo at yahoo.com> [0403 18:03]:

> The following basic problem still hasn't been solved:
>   given two gems A and B, such that A depends on B, does some specific B
>   (i.e. some version of it) satisfy A's dependency (i.e. make it work ok,
>   not only satisfy whatever's specified in the gemspec)?

You mean API features etc?  That would obviously be nice, but not essential -
so long as what rubygems provides is better than the alternative, that's 
'good enough' - all packages I've used in the last year have explicitly
specified a minimum required version of packages it uses, so I'd expect
this to be more intuitive for gem writers.

In an ideal world, the developer will be using gems during development,
so he knows "amrita 1.0 or higher" is enough.

> It won't be possible to create the dependency tree (a correct one that
> is) until that is done.

A gem doesn't need to be aware of a whole tree of dependencies - you
specify what *you* need. Your dependencies in turn pull in what they
need, but no single object needs see the entire tree.

You can still ask a gem to recursively list its dependencies,
and they in turn list their deps, etc, etc.

The uninstall safety check doesn't affect that in any case, so I'll shut
up about that :)

> > >> IMHO, just like when installing, Rubygems should ensure that the system
> > >> is not left in a broken state when removing packages.

> > I don't think it's that urgent.  The gem population is small enough at
> > the moment [1] that you can easily uninstall everything and reinstall
> > what you need in a short time.

Well, yes, but you could argue the same thing for the installation of
dependencies in the first place :) No other package system I know of
lets you break a dependency tree without warning you; again
I'm trying to think of POLS (mine, of course).

I'm not trying to hold anything up - I only just walked in !
0.3.0 looks a lot more complete than 0.2.0, so it needs to go out, but
since dependency tracking is a core feature, it should be at least usable. 

I'd like to help sort it, but there's no point if everyone thinks its an ugly
hack, or there's a roadmap that will make it obsolete.

 I don't mind doing the work to fix it
( using my planB 'will you miss me when I'm gone?' cache trick I mentioned).
I should be able to send a patch by the beginning of the week -
 possibly tonight, depending if that noise is just Mani stirring upstairs,
or if she's going to be awake all night 
[ TeleTubbies takes precedence over Ruby in that case ]..

If it's late, or it's crap, I'll try again after 0.3.0 goes out.
For the minute, I just wondered if this was an acceptable way to fix a 
problem that ideally would be in the next version.

Rasputin :: Jack of All Trades - Master of Nuns

More information about the Rubygems-developers mailing list