Re: Core support for Gems, and namespace

On Wed, 28 Jul 2004 11:29:53 +0900, Gavin Sinclair
<[e-mail]> wrote:
> On Wednesday, July 28, 2004, 3:23:46 AM, Austin wrote:
> [long and interesting post snipped because there's not one
> particular part I wish to reply to]
> 
> Austin,
> 
> I don't want to ram library versioning down anyone's throat, but
> on the one hand, you say you don't like the fact that RubyGems
> bothers with versioning (it's overengineering, and you don't see a
> use for it), and on the other hand, you point out two very good
> reasons to have it: allowing apps/libraries to cope with changes
> to APIs in other libraries; and avoiding "CPAN upgrade hell".
> 
> Since there are two good reasons to tackle versioning, why not
> embrace it?

Well, there's a few problems.

1. The binary and site_lib stubs breaks the versioning concept, and
   there are other problems with the use of them from the developer/
   deployment perspective. (I had to change ldiff in diff-lcs to not
   use the "if __FILE__ == $0" common feature. It is expected that
   the loaded file will return an error code -- and not all "bin"
   files are written that way.)

2. The disconnect between "require_gem 'diff-lcs'" and the nominal
   "require 'diff/lcs'" is more than annoying, it's problematic. It
   means that I can really only provide one loading mechanism for a
   given library, whereas I might theoretically have more than one.
   This is, in fact, a possibility with Diff::LCS; if you are
   working with Arrays extensively, you can simply require
   "diff/lcs/array" and it will require everything else. Now, I have
   to do "require 'diff/lcs'" and "require 'diff/lcs/array'"
   separately. In this way, the gem versioning has explicitly broken
   a desired interface.

3. Certain types of changes should not be permitted to exist
   simultaneously (e.g., diff-lcs-1.0.1 and diff-lcs-1.0.2), whereas
   others should be acceptable (e.g., the upcoming diff-lcs-1.1.0 vs
   diff-lcs-1.0.2). This can't be solved by RubyGems alone, but
   there is no way for me, as a developer, to mark older gems as
   obsolete and incompatible with earlier versions.

4. The general case will be one version of a given library. Changing
   between the standard mechanism and the versioning gem mechanism
   is *painful* for library and application writers. The only way to
   take advantage of it is to package your application as a gem, and
   that's not always appropriate. In fact, Alan and I are looking at
   packaging Ruwiki as a Gem, and I have concerns about the
   appropriateness of that. IMO, an rpa-base package is more likely
   to be usable, but even then, Ruwiki may be a special case. Ruwiki
   is now going to be depending on Diff::LCS, but we are going to
   package the portions of the required version inside of Ruwiki
   packages as we have been doing with Algorithm::Diff. This is
   easier for us as a standalone application than relying on any
   external packaging mechanism.

5. I haven't used require_gem. Ever. At this point, because the
   require target is different and I don't have any libraries that
   actually require specific versions of packages *and* I don't want
   to require users actually have to have RubyGems installed, I
   don't actually see using it. I only did some changes to ldiff in
   Diff::LCS to better match RubyGems capabilities. I don't
   personally ever see using the require/rescue form. I actually
   spend time making sure that my libraries are laid out
   intelligently, and RubyGems doesn't let me handle that. I agree
   with Luke that a 'require "foo/dependencies"' is not the right
   way to do this, as it raises the dependencies from the level that
   they probably belong to (e.g., Ruwiki's dependency on Diff::LCS
   is, in fact, only in the flatfile backend -- not in the program
   itselff, yet).

The concepts behind RubyGems are wonderful. There are a number of
great things that the RubyGems team has done. I'm just not sure that
RubyGems versioning is ideal. I don't have an alternative solution,
just a vague dissatisfaction with what's there now.

-austin
-- 
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]