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.