Jim Weirich wrote:
>>>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.

I had, at some point or another, envisioned a transparent distributed
system where a given server not only delegates out downloads but the
very indexing itself to any other servers it knows about. I can not
recall if I wrote any code for this but it is quite doubtable as I
usually would do no such thing :)

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

E
-- 
No-one expects the Solaris POSIX implementation!