[Rubygems-developers] PATCH: respect requirements of gems
batsman.geo at yahoo.com
Thu Apr 22 16:46:50 EDT 2004
On Thu, Apr 22, 2004 at 09:00:06PM +0100, Dick Davies wrote:
> > 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.
One of the major design decisions for Rubygems was allowing several
versions of a lib to be installed; however the requirement/dependency
subsystem is not up to the task (yet). I do believe ensuring the lib
actually used has the correct API is *essential*, and see the API as a
part of the dependency actually.
The basic problem is that even if you coded the satisfied? method you
talked about, there's *no way* atm. to ensure it won't return bogus
results because there's no consistent versioning scheme as far as the
API is concerned.
> In an ideal world, the developer will be using gems during development,
> so he knows "amrita 1.0 or higher" is enough.
That's not good enough, cause 1.1 could break source compatibility and
he wouldn't notice until the program breaks. And this might happen much
later, since amrita could have been upgraded when installing some other
unrelated gem (as you surely know, require_gem will take the latest
installed version by default). The easiest (and AFAIK only) way to
handle that is have whoever's doing the gem for amrita specify API
compatibility, and the simplest way to do so I'm aware of is using an
internal API numbering scheme (see Eivind's postings).
If anybody knows another solution, plz do tell; so far nothing else has
been proposed that addresses the issue completely.
> > 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.
I didn't imply that a gem needed the full dep. tree, just meant that
atm. a gem can't even specify its deps. precisely.
> > > >> 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  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
We fully agree on this; I just see the API as a part of the dependency.
> I'm trying to think of POLS (mine, of course).
I see things breaking unknowingly to me when upgrading/removing gems as
a *very* bad surprise :P
> I'm not trying to hold anything up - I only just walked in !
Plz take a look at
http://rubyforge.org/pipermail/rubygems-developers/2004-April/000294.html + replies
for some context.
> 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 don't mind doing the work to fix it
> ( using my planB 'will you miss me when I'm gone?' cache trick I mentioned).
As I said, the patch would be fine but w/o something like
(straightforwardly implemented in
the #satisfied? method can't be implemented reliably.
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
If loving linux is wrong, I dont wanna be right.
-- Topic for #LinuxGER
More information about the Rubygems-developers