[Rubygems-developers] PATCH: respect requirements of gems
rasputnik at hellooperator.net
Fri Apr 23 23:39:51 EDT 2004
Mauricio Fernández wrote:
> On Fri, Apr 23, 2004 at 07:33:26AM -0400, Chad Fowler wrote:
[snip me talking about dependency checks on uninstall]
>>>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,
> What's wrong about requiring a specific internal version numbering
> scheme? I mean, the gemspec already requires rubygems_version, name,
> platform, date, summary, require_paths, version; what's so wrong about
> adding api_version to the list? Keep in mind that people would still be
> free to use whatever scheme they like for the 'main' version number.
If that functionality is needed for a particular gem, then the option
certainly needs to be available. Personally I don't see it being
as essential as a version number ( I'm used to package systems where
that's all there is, and it seems to scale OK), but if that's useful
in some cases its something that needs addressing.
The point of the satisfied? method was that you can pass a list of
installed gems (or a list of 'what will be installed' gems in the case
of this uninstall check I was referring to originally) to a Dependency
and let it do that kind of checking for you.
If the gem has a need for more detailed checking, it can use
any extended versioning or API requirements in its Dependency to decide
if it's happy with what gems are/will be available. If it's a simpler
gem, and the libraries it uses are well-behaved and backwards
compatible, it can do a simple version check.
I just think that tucking those checks and queries into the Dependency
saves you having to do the work in the (un)installer.
More information about the Rubygems-developers