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

Luis Lavena luislavena at gmail.com
Tue Sep 30 23:09:27 EDT 2008

On Wed, Oct 1, 2008 at 12:45 AM, Jim Freeze <rubygems at freeze.org> wrote:
> 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. :/

Ok, let forget about bunny_foo_foo, require_gem and all that, let's
heard the complains.

1st: who are the users that are complaining to you? what is your role
in the company or what?

2nd: users using these gems should at least know how to use the gems.

3th: even we implement bunny_foo_foo in RubyGems your users using
Debian and installing "the debian way" or any other bizarre distro
maybe will not depend on RubyGems.

4th: These non-standard or non-standarized "requires" should be
forwarded to each gem author or teams and not being handled by

5th: If the projects are OSS (which most of the gems are), contribute,
send patches or Fork (in case of a Git repository or even using

Luis Lavena
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

More information about the Rubygems-developers mailing list