[Rubygems-developers] Committed: generate library stub on install

[Chad Fowler]

On 26/4/2004, at 11:56 AM, Gavin Sinclair wrote:

> Well, I've ironed out the errors, and it seems to work, but like
> Chad's latest effort, this needs a lot of testing, and some discussion
> as well.
>
> For example, after installing the 'fingerserver' gem:
>
>   $ cat /usr/local/lib/ruby/site_ruby/1.8/fingerserver.rb
>   #
>   # This file was generated by RubyGems.
>   #
>   # The library 'fingerserver' is installed as part of a gem, and
>   # this file is here so you can 'require' it easily (i.e.
>   # without having to know it's a gem).
>   #
>
>   require 'rubygems'
>   require_gem 'fingerserver'
>


Cool!

It looks like your --install-stub flag is passed all the way down to 
the place where you would use it and then subtly ignore. :)  I may be 
wrong, but you might want to have a look.

>
> It's nothing terribly different from the application stub.  Which, by
> the way, I'm not sure works (see other thread).... :-\
>
> Issues with this feature:
>  - if you don't have write access to the site_ruby/1.x directory,
>    tough luck


If you can manage to get the functional tests to work, this would be a 
nice test to add (sane handling of permissions issues) and then fix. :)

>  - it's not cleaned up during uninstall (same as app stub)

Whoops!  Forgot about that with the app stub thing.

>  - it only stubs the 'autorequire' file
>    - this is intentional, but not well thought out

I think that's fine, personally.

>    - it means that you can't go straight ahead and require
>      x/y when x is the autorequire

But, you *could* require 'x' and then require 'x/y' if you were so 
inclined.

>      -> this is a hole in the 'backwards-compatibility' layer, and
>         will probably bite (only) a few people at some point
>

Agreed.  We could hack require to deal with it, but I don't think it's 
worth getting in Ruby's nether regions.

> Good night!
>
>

And to you.