On Oct 1, 2005, at 9:25 PM, Ryan Leavengood wrote:
> Either way, as Jim says your use cases are supported in the latest
> RubyGems, though now that is has been brought up, I'd like to play
> with some of my old ideas again.

Please do!  :)

Say that you had two implementations of gems with identical feature  
sets, but one used the "gem" command to do everything and one let you  
use .gem files directly.  I would *much* prefer using the latter.

Though I am glad that Jim says my use cases are supported, I still  
feel that having to interact with the system using an opaque command  
like 'gem' is inferior to being able to interact with my filesystem  
directly.  It also will make me worry that in the future I'll run  
into an unsupported use case I hadn't thought of.

> Based on recent discussions though, I wonder if RubyGems need to be
> re-written for a third time (though strictly speaking my first
> revision really was a prototype and didn't have even close to the
> feature-set of the current system.)

Yes, I don't know the details of the current controversy (ie. why  
Debian is having a problem packaging gems), but standardizing on a  
gem format that is at odds with OS packages seems like a very bad idea.

Josh