Re: RubyGems TODO

On Thu, Sep 22, 2005 at 11:46:18AM +0900, Chad Fowler wrote:
> Thanks, Why.  I'd like to add (at least, for now):
> 
> 5. Refactor the way gem indexes work.  It's gotten too big.  This is  
> high up on the TODO list because we're eating up too much RubyForge  
> bandwidth, and remote installs have gotten slow again.  I believe Jim  
> is working on it concretely tonight.
> 6. Unify the way we deal with local and remote installs.  This has  
> also been on the radar for some time, and it should happen pre- 
> ruby-1.8.4.

To the extent that the above don't affect the source code shipped by
upstream, I'd say they're less important than the other changes.

For instance, the longer it takes to remove/rename require_gem, the more
people will be affected by the deprecation process. So there's some
sense of urgency associated to the fixes that imply changes in the
upstream sources.

> 7. Rename "require_gem".  This will break some things (we can always  
> deprecate it out slowly), but as we go away from _needing_  
> require_gem, we should take the chance to name it properly.  It will  
> be something more like "use_gem".  Many name ideas have been  
> proposed.  We'll pick a good one.  The purpose will be to still  
> provide an optional way to lock down versions (for things like Rails,  
> where it's a ubiquitous practice).

I was going to reply that just renaming require_gem was not enough, that
it should be removed altogether and the optional version specification added
to Kernel#require.

On second thought, I see that having a use_gem which only adds something
to $: is not really that bad repackaging-wise. Repackagers would
have to make sure it becomes a non-op in their Ruby distribution
if they don't want packages installed through their systems to be
dependent on RubyGems. Please note however that such a use_gem should
not do anything else; in particular, auto_require would introduce an
incompatibility between RubyGems-dependent and other systems. This is
why I had listed auto_require as a source of problems in the current
RubyGems implementation. We talked about that around one year ago:

http://rubyforge.org/pipermail/rubygems-developers/2004-September/000979.html

Still, while 
  use_gem 'X' # X == RubyGems package name
is not harmful repackaging-wise, I'm unconvinced about its relative
merits compared to for instance  
  require 'x', "1.2"    # x = name of .rb or ext file

The former identifies RubyGems to Ruby(i.e. language)-level "packages"
(comparable to those in Java or other languages), but I think this is
an important change in the language that deserves being considered
separately.

In practical terms, I'd suggest that (7) become one of the following:

* dump require_gem and auto_require, add the ability to demand a specific
  version to Kernel#require, in such a way that it is possible to ignore such
  version requirement if the distributor uses another system (for instance, it
  is possible to resolve this semi-statically).
* deprecate auto_require and rename require_gem: the latter is not really
  indispensable but it'd help in the deprecation process since upstream would
  just have to make sure he turns all require_gem into use_gem+require.

-- 
Mauricio Fernandez