Okay. I said in the main thread on ruby-core that I'm putting together a
proposal for this. Here's the set of proposals. I would happily assist
in the development of any of these, but I am completely swamped until
after RubyConf. None of the problems are conceptually difficult and I
believe that the model that we should encourage is that package
maintainers should trust RubyGems to do its job properly, because it
does its job a *lot* better than CPAN does (IMO). To be clear, I *do
not* think that we should encourage the manual unpacking and
installation of gems and that if repackagers do that, they're doing
something that is contraindicated and they're hanging their users out to
dry.

This list, obviously, is my opinion. None of this eliminates other
possible improvements already on this thread.

1. require_gem needs to go away. We still need a way of saying that gem
   foo-1.3.5 represents foo/bar version 1.3.5, but I believe that this
   can be done with modifications to Kernel#require to accept a version
   parameter. The drawback, of course, is that this means that the
   require code has to be smarter. Eliminating require_gem will also
   eliminate the auto_require feature, something I think I'm going to
   get rid of from my own gems moving forward in any case.

2. If require_gem is eliminated and replaced with activation (per
   earlier discussions, also #4 on Chad's -core list), then we can even
   get RPA-like "stable release suite" concepts, so that you can have a
   metagem (no different than a real gem) such that you might do:

     require 'gemreview/rails', '1.0.0'

   This could activate a series of gems related to Rails produced by the
   "gemreview" team. Activation would be the equivalent of locking a
   gem's path into $LOAD_PATH.

   The search order should be:

     manually activated gems
     site_ruby
     installed gems
     ruby-lib

3. Eliminate case-sensitivity. Having a Usage gem or a RedCloth gem is
   confusing. At the same time, I will also acknowledge that there's a
   mismatch between gem names (e.g., pdf-writer, color-tools) and what
   they provide (e.g., pdf/writer and color). There's got to be a better
   way to handle gem naming issues and mapping issues. This is, IMO,
   vital to #2.

4. DATADIR must be addressed. However, it must be addressed in a Ruby
   and RubyGems way. That is to say that I need something like
   $DATA_PATH as an equivalent for $LOAD_PATH, and I need versioning.
   Ruwiki includes its documentation as a read-only wiki that's
   installed with Ruwiki. It also has a version-specific default
   package. PDF::Writer needs this less, but I absolutely need a way --
   in code -- that I can get a clean data directory that will work
   whether or not a package is installed as a gem. This is an
   opportunity to fix what I consider a Ruby problem. Also note that
   IMO, this is especially important on Win32, as what's in rbconfig MAY
   NOT be in the same place as when it was built. I don't think this is
   a huge issue, here, but it's still important. Unless the DATADIR
   solution is solved in a version-aware way, however, I will continue
   to package data relative to __FILE__, and I will continue to Not Care
   what this does to repackagers -- because I know what my application
   requires.

5. T.'s problem of detecting manual installation dependencies is a good
   one, and I'm not sure that there's a good answer. Ultimately, it's
   not a problem when *running*, but perhaps RubyGems should be a little
   more tolerant of missing gem dependencies.

6. Post-installation message capabilities. Let me give the user a
   message to see after they've installed the gem.

7. It might be useful to have a LICENCE field so that users could
   possibly develop installation policies (for those zealots who won't
   install anything that isn't GNU GPLed).

8. This is also not completely Gem related, but it would be nice, for
   extensions, to be able to detect where one's development environment
   might be on Windows.

9. External (e.g., non-Ruby) dependencies references would be useful.
   I'm thinking something like:

     spec.external_dependencies = { 'ImageMagick' => 'http://....' }

10. "Optional" dependencies. That is, things that aren't *required* to
    make the gem work, but can add additional functionality. This would
    apply to both gem dependencies (as Text::Format can use
    Text::Hyphen, but doesn't require it for basic operation) and
    external dependencies.

11. Architecture-dependent and architecture-independent directories.
    This is potentially a big shift in the way things work, as it goes
    out of the dir-per-gem-version style. Sort of. The current
    installation is something like:

      /usr/local/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo.rb
      /usr/local/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo/bar.so

    (This is approximate, nothing more. I don't have any compiled gems
    handy to verify). There's no reason that can't be changed to:

      /usr/share/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo.rb
      /usr/local/lib/ruby/i386-linux/gems/1.8/gems/lib/foo/bar.so

    or something like that. Up front, I don't really care HOW it's done.
    Since it will be in a predictable prefix location with a predictable
    path pattern, it shouldn't be significantly harder to remove on
    uninstall than the current dir-per-gem-version mechanism. In this
    way, RubyGems can help those who give a damn about FHS or LSB the
    tools they need to make things work while not forcing the rest of us
    who don't care to adapt to their particular neurosis.

    This would ideally require a "gem rebuild" command or something to
    force the arch-dependent stuff to be rebuilt.

12. Add the Rake support patch. (There's a patch available to allow
    Rake-driven extension builds.)

Incomplete, but I think it's thorough and covers the current discussion.

-austin