Re: RubyGems TODO

>> On 21-Sep-05, at 7:17 PM, why the lucky stiff wrote:

>>> So, what needs to happen with RubyGems to neutralize everybody?
[... items 1..4 elided ...]

Chad Fowler said:

>> Thanks, Why.  I'd like to add (at least, for now):
[... items 5..7 elided ...]

This is how I would sort the Why/Chad todo list:

* Things that are Urgent and need done immediately:

(5) Incremental Source Index downloads.

    I understand that RubyForge is currently having issues with the
    large monolithic index file, which makes this a high priority
    item.  I meant to deal with this earlier, but got sidetracked with
    life.

* Things that should be done for a 1.8.4 merge:

(1) Data dir support.

    This is really more of an issue with the Ruby environment rather
    than with RubyGems itself.  The reason it tends to come up in
    RubyGems context is that it is gems that people want to package.

    I have some vague suggestions in this area, but the discussion
    should probably move to a different thread.  I'll post more when I
    organize some thoughts.

(3) Semantics of require and needing to require rubygems.

    In the absence of explicit require_gem commands, RubyGems only
    interfers with the require process when a file cannot be found by
    the normal require process.  In order to do this, it currently
    aliases Kernel.require and traps load errors.

    I would like to see two things happen as RubyGems becomes part of
    the core.  (1) a general hook for require LoadError handlers be
    implemented, and (2) RubyGems become a default handler in that
    hook.  This keeps the impact of RubyGems at an absolute minimum
    until the moment it is needed, but users can get to gems without
    doing explicit require 'rubygems', -rubygems or RUBYOPT hacks.

(7) Deprecate require_gem and start using use_gem (or an appropriate
    alias).

* Good things that are necessarily needed for 1.8.4 merging.

(6) Local / Remote installer unification.

    This is a major area of functionality that really needs to be
    addressed.  Fixing this will fix a number of inconsistancies with
    the way local gems are handled.

    Chad would like to see this before 1.8.4, and I agree; but this
    change is big enough that it will probably need some extensive
    burn in time, so I am hesitant to insist that it be prior to
    1.8.4.

(2) gem setup / gem lint

    Excellent ideas.

* Vague items that need more definition

(4) Distro compatibility.

    I think the DATADIR issue will go a long way to resolving some of
    these issues.  But I would like to hear specifics in this area.
    Although RubyGems is primarily a *Ruby* packaging system (and so
    our priorities are set accordingly), we certainly don't want to
    make it any harder for repackagers and specific suggestions are
    always welcome.

-- 
-- Jim Weirich     [e-mail]    http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)