I've just been reading the recent threads about gems.  I don't have  
much background on this issue, but I have a few questions/concerns  
about the current state of gems.

My primary question is: why do I have to "install" a gem?  What about  
the gem design would make it fundamentally impossible for Ruby to  
load a .gem file directly?

Think how great it would be if "installing a gem" was equivalent to  
"putting the gem file in your RUBYLIB path."  What could be simpler?   
Sure, you couldn't put checks in place to make sure I've installed  
all the right dependencies, but you'll figure that out at runtime,  
when I try to load that gem (or you could use "gem check").

My concern with the current design is that it is too inflexible.  It  
imposes a model where you have to use the "gem" command to do  
anything, and you have to hope that your use case is one of the  
operations that "gem" supports.  For example, can gems support these  
use cases?

- I want to try out a gem on a system where I don't have root.  (or  
where I don't want to install the software globally yet)

- I want to have more than one local gem repository (eg. /usr/lib  
vs. /usr/local/lib), and I want dependencies to be fulfilled across  
repositories (eg. a gem in /usr/lib can have a dependency be  
fulfilled by a gem in /usr/local/lib)

- I want to install a gem from a gemfile I already have (ie: don't  
fetch it from the network)

- I want to "unpack" a gem into a directory structure that can be  
deployed to another machine, without having to run "gem" on the  
remote machine (and without updating any global index on my current  
machine)

- same as the previous one, but I also want to "unpack" the gem into  
a different directory root than where it will live on the remote  
machine.  I may not even know what directory it will live in on the  
remote machine.

What I don't like is the feeling that the "gem" command is a  
gatekeeper between you and your system -- you have to go through it  
to get anything done.  And it hides the details of what's going on,  
making the system very opaque.  It was difficult for me to figure out  
which of the above use cases are supported, because the rubygems  
documentation doesn't tell you the details of what "gem" does.

If Ruby could load .gem files directly, you would immediately support  
any use case, because they would be as flexible as single .rb files:

-  "cp foo.gem /path/to/my/RUBYLIB" could be used in place of "gem  
install" (you could still use "gem install" to query remote servers  
if you want)

- "rm foo.gem" could be used in place of "gem uninstall"

- "ls foo*.gem" could be used in place of "gem list"

I think this would make the system more flexible and transparent.  I  
would argue that any properties of the gem format that make this  
impossible should be reconsidered.

Josh