[Rubygems-developers] PATCH: respect requirements of gems

[Chad Fowler]

On 22/4/2004, at 4:46 PM, Mauricio Fernández wrote:

> 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.

Same here.  See the larger paragraph below.


>>
>> 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.
>>
>> [Gavin]
>>>> 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
>
> We fully agree on this; I just see the API as a part of the dependency.
>

I do too.  And, I think everyone who knows anything about programming 
would too.  But, I don't think we have to enforce everything in code, 
in the same way that I don't think we have to check "type" for method 
parameters, or make everyone follow the same naming conventions with 
code.  I believe the inclusion of Jim's additional 1.*.* kind of thing 
will give us the functionality we need to *recommend* a sensible 
convention for version numbering of gems.  And, the community in actual 
practice will adhere to it.  There may be a bump or two occasionally, 
just like occasionally someone changes an API without warning everyone 
and breaks code or makes a change in CVS that has unintended 
consequences.  It's then caught and fixed.  We can't write code to 
guard against every eventuality.  We can write enough code and give 
users a framework so that it's *possible* to do the right thing, but 
I'm very much against trying to enforce policy like this via code.  I 
believe Jim's idea is what is needed to move us in the right direction 
w.r.t versioning.

My feeling is that this isn't nearly as big a deal as it's being made 
out to be.


>> 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
>

Obviously.