[Rubygems-developers] Gem Names not correlated to require name

Jim Freeze rubygems at freeze.org
Tue Sep 30 22:45:02 EDT 2008


On Tue, Sep 30, 2008 at 8:53 PM, Austin Ziegler <halostatue at gmail.com> wrote:
> On Tue, Sep 30, 2008 at 9:03 PM, Jim Freeze <rubygems at freeze.org> wrote:
>> So, I did not realize that require_gem was such a loaded word.  And
>> somehow is sucked in autorequire. Who mentioned that?
>
> You did, but you didn't realize it.

No, I didn't.

> #require_gem *was* a method that would work like this:
>
>  require_gem 'pdf-writer', '= 1.1.8'
>
> Looks a lot like the #gem method, right? Well, it is almost exactly
> like the #gem method, except that it did one other thing: it looked at
> the autorequire field in the gem spec, and then loaded whatever file
> (or files?) were in there.

What I am suggesting will NOT use autorequire. Really. Not. Nada.

> If I install ParseTree (for example) with "apt-get ruby-parsetree",
> should I expect the ParseTree gem to be installed? Well, ideally, yes.
> But the Debian maintainers, in their infinite wisdom, don't like
> RubyGems and don't use it so far as I can tell. So, if I've got a
> script that runs on multiple platforms, including a Debian system, I
> have to make my program look something like this in a #bunny_foo_foo
> world:
>
>  begin
>    bunny_foo_foo 'ParseTree'
>  rescue <something>
>    require 'ParseTree'
>  end

Ok, now we are getting somewhere. The same applies today with rubygems.

 begin
  require 'some-lib'
 rescue LoadError
  require 'rubygems'
  require 'some-lib'
 end

> Which is just what you're already complaining about. Note that I put

No, it's not. And I'm not complaining. I am getting complaints. Man,
doesn't anyone read. :/

> It might be NoMethodError (because if you don't have RubyGems
> installed, you don't have #bunny_foo_foo); it might be LoadError; it

Actually, bunny_foo_foo could be built in.

> This is a real problem, but it's the same problem that exists on any
> packaging system. You want the package names to be sensible, but a
> package may offer more than just one thing to load. Consider Facets.
> While I don't particularly like this library, it's an excellent
> example of the problem: it's a mega-library that contains a lot of
> different useful functionality that you don't always want to load all
> of it all of the time.

Yes, this suggestion won't work for multi-featured gems. Rails is a
good example too.

> Does Trans force people to install 25 gems to allow an autorequire
> mechanism to work on a fine-grained enough level (which means you now
> have to remember 25 different gem names...), or does he go with one
> gem that people choose "require 'facet/feature1'" and "require
> 'facet/feature2'" instead? And, if they want, he could offer a
> lib/facets.rb that includes all 25 features.

Again with that autorequire thing. Are all computer people so locked
in to existing ideas they can't see alternatives. What if
bunny_foo_foo took arguments.

 bunny_foo_foo 'facets', :feature_2459592

>> Today, gem developers can solve this problem in
>> the following manner:
>>
>>  sudo gem install bora_bora
>>  ....
>>  require 'rubygems'
>>  require 'bora_bora'  # look, no surprise here.
>>
>> where the bora_bora gem has included the file lib/bora_bora.rb with the contents
>>
>>  require 'my/crazy/path/that/you/cant/guess'
>>
>> But, we can refactor these two lines into a single line
>>
>>  require_gem 'bora_bora'
>>
>> I mean
>>
>>  bunny_foo_foo 'bora_bora'  # optional version follows
>>
>> So, here the file lib/bora_bora does not have to exist. It could
>> possibly be lib/bootstrap.rb. This file will then require the correct
>> files. You know, the mysterious ones that I've been getting complaints
>> on.
>>
>> Also, notice there is no suggestion of autorequire here. This simply
>> replaces the "require 'secret/path'".
>
> It's still autorequire, even if bunny_foo_foo looks for lib/bootstrap.rb.
>
> Why? If I have five gems with lib/bootstrap.rb, what happens when I do:
>
>   require 'bootstrap'
>
> One of them will be activated, but it may not be the one you expect.

I expect the same thing I have today (that magically doesn't use autorequire).

I have 5 versions of the sequel gem. What happens when I do:

require 'rubygems'
require 'sequel'

It requires the latest version. What is so special about this that it
doesn't use autorequire, but bunny_foo_foo does?

-- 
Jim Freeze


More information about the Rubygems-developers mailing list