Recursive install-stub for gems?

Discussion in 'Ruby' started by Robert Feldt, Aug 16, 2004.

  1. Robert Feldt

    Robert Feldt Guest

    Hi,

    Sorry if this is obvious; I haven't really been following the RubyGems
    hopla. However, I searched but didn't find an answer so here goes...

    Shouldn't "gem install X --install-stub" work recursively so that not
    only the top-level loading of the gem is done but it also works for
    files deeper down in the dir?

    Example:

    gem install net-ssh --install-stub

    install net/ssh.rb which is stub that loads the gem. However, when I
    have installed net-ssh I would expect

    require 'net/ssh/sftp'

    to work out of the box. It currently doesnt.

    Any plans to fix this or am I missing something?

    /Robert Feldt
    Robert Feldt, Aug 16, 2004
    #1
    1. Advertising

  2. Robert Feldt

    Chad Fowler Guest

    On Tue, 17 Aug 2004 06:47:26 +0900, Robert Feldt <> wrote:
    > Hi,
    >
    > Sorry if this is obvious; I haven't really been following the RubyGems
    > hopla. However, I searched but didn't find an answer so here goes...
    >
    > Shouldn't "gem install X --install-stub" work recursively so that not
    > only the top-level loading of the gem is done but it also works for
    > files deeper down in the dir?
    >
    > Example:
    >
    > gem install net-ssh --install-stub
    >
    > install net/ssh.rb which is stub that loads the gem. However, when I
    > have installed net-ssh I would expect
    >
    > require 'net/ssh/sftp'
    >
    > to work out of the box. It currently doesnt.
    >
    > Any plans to fix this or am I missing something?
    >


    You're not missing anything. We're planning to add the ability to
    specify other files that can be stubbed. Right now, though you *can*
    do:

    require_gem 'net-ssh'
    require 'net/ssh/sftp'

    Would our proposed change work? We are avoiding stubbing every single
    file in the lib, and allowing gem authors to specify the ones that
    would make sense (as in sftp).

    Thanks!
    Chad
    Chad Fowler, Aug 17, 2004
    #2
    1. Advertising

  3. On 8/16/04 5:47 PM, "Robert Feldt" <> wrote:

    > Hi,
    >
    > Sorry if this is obvious; I haven't really been following the RubyGems
    > hopla. However, I searched but didn't find an answer so here goes...
    >
    > Shouldn't "gem install X --install-stub" work recursively so that not
    > only the top-level loading of the gem is done but it also works for
    > files deeper down in the dir?
    >
    > Example:
    >
    > gem install net-ssh --install-stub


    FYI: As of the next version, the stub is default so... --install-stub is not
    longer necessary.

    >
    > install net/ssh.rb which is stub that loads the gem. However, when I
    > have installed net-ssh I would expect
    >
    > require 'net/ssh/sftp'


    This is interesting. Knowing that the stub first loads rubygems, then does
    a require_gem, we could do a few things:

    1) allow the developer to specify which stubs get generated which target
    files under their path:

    gemspec.stubs = ['net/ssh', 'net/ssh/sftp']

    Or...

    2) have a person have to do:

    require 'net/ssh'
    require 'net/ssh/sftp'

    That will currently work.

    I like the former for a long term fix though...but this does force an order
    by a library author on which files are directly "require'able".

    >
    > to work out of the box. It currently doesnt.
    >
    > Any plans to fix this or am I missing something?
    >
    > /Robert Feldt
    >
    >
    >
    Richard Kilmer, Aug 17, 2004
    #3
  4. On Tuesday, August 17, 2004, 10:52:48 AM, Chad wrote:

    >>
    >> Shouldn't "gem install X --install-stub" work recursively so that not
    >> only the top-level loading of the gem is done but it also works for
    >> files deeper down in the dir?
    >>


    > You're not missing anything. We're planning to add the ability to
    > specify other files that can be stubbed. Right now, though you *can*
    > do:


    > require_gem 'net-ssh'
    > require 'net/ssh/sftp'


    > Would our proposed change work? We are avoiding stubbing every single
    > file in the lib, and allowing gem authors to specify the ones that
    > would make sense (as in sftp).


    Thanks for answering, Chad. I'm working on this feature at the
    moment.

    Robert and others: should it stub every file, or should gem authors
    decide which files are to be stubbed?

    Gavin
    Gavin Sinclair, Aug 17, 2004
    #4
  5. Robert Feldt

    Robert Feldt Guest

    Gavin Sinclair wrote:

    >On Tuesday, August 17, 2004, 10:52:48 AM, Chad wrote:
    >
    >
    >
    >>>Shouldn't "gem install X --install-stub" work recursively so that not
    >>>only the top-level loading of the gem is done but it also works for
    >>>files deeper down in the dir?
    >>>
    >>>
    >>>

    >
    >
    >
    >>You're not missing anything. We're planning to add the ability to
    >>specify other files that can be stubbed. Right now, though you *can*
    >>do:
    >>
    >>

    >
    >
    >
    >>require_gem 'net-ssh'
    >>require 'net/ssh/sftp'
    >>
    >>

    >
    >
    >
    >>Would our proposed change work? We are avoiding stubbing every single
    >>file in the lib, and allowing gem authors to specify the ones that
    >>would make sense (as in sftp).
    >>
    >>

    >
    >Thanks for answering, Chad. I'm working on this feature at the
    >moment.
    >
    >Robert and others: should it stub every file, or should gem authors
    >decide which files are to be stubbed?
    >
    >
    >

    Chad and others: I think the latter solution is best; stubbing every
    file seems awkward and the author can influence what people expect to be
    stubbed in the docs etc. I wouldn't mind spec'ing it in the GemSpec.

    Thanks,

    Robert
    Robert Feldt, Aug 17, 2004
    #5
  6. Robert Feldt

    Chad Fowler Guest

    On Tue, 17 Aug 2004 16:21:10 +0900, Robert Feldt <> wrote:
    > >
    > >

    > Chad and others: I think the latter solution is best; stubbing every
    > file seems awkward and the author can influence what people expect to be
    > stubbed in the docs etc. I wouldn't mind spec'ing it in the GemSpec.
    >
    > Thanks,
    >
    > Robert
    >


    Robert, thanks for your input!

    Chad
    Chad Fowler, Aug 17, 2004
    #6
  7. On Tue, 17 Aug 2004 16:21:10 +0900, Robert Feldt <> wrote:
    > Gavin Sinclair wrote:
    > >On Tuesday, August 17, 2004, 10:52:48 AM, Chad wrote:
    > >>>Shouldn't "gem install X --install-stub" work recursively so that not
    > >>>only the top-level loading of the gem is done but it also works for
    > >>>files deeper down in the dir?
    > >>You're not missing anything. We're planning to add the ability to
    > >>specify other files that can be stubbed. Right now, though you *can*
    > >>do:
    > >>require_gem 'net-ssh'
    > >>require 'net/ssh/sftp'
    > >>Would our proposed change work? We are avoiding stubbing every single
    > >>file in the lib, and allowing gem authors to specify the ones that
    > >>would make sense (as in sftp).

    > >Thanks for answering, Chad. I'm working on this feature at the
    > >moment.


    > >Robert and others: should it stub every file, or should gem authors
    > >decide which files are to be stubbed?

    > Chad and others: I think the latter solution is best; stubbing every
    > file seems awkward and the author can influence what people expect to be
    > stubbed in the docs etc. I wouldn't mind spec'ing it in the GemSpec.


    Why not offer both? That is, give the spec author a simple token that
    can be detected to stub everything in the lib directory?

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Aug 17, 2004
    #7
  8. On 8/17/04 8:05 AM, "Austin Ziegler" <> wrote:

    > On Tue, 17 Aug 2004 16:21:10 +0900, Robert Feldt <> wrote:
    >> Gavin Sinclair wrote:
    >>> On Tuesday, August 17, 2004, 10:52:48 AM, Chad wrote:
    >>>>> Shouldn't "gem install X --install-stub" work recursively so that not
    >>>>> only the top-level loading of the gem is done but it also works for
    >>>>> files deeper down in the dir?
    >>>> You're not missing anything. We're planning to add the ability to
    >>>> specify other files that can be stubbed. Right now, though you *can*
    >>>> do:
    >>>> require_gem 'net-ssh'
    >>>> require 'net/ssh/sftp'
    >>>> Would our proposed change work? We are avoiding stubbing every single
    >>>> file in the lib, and allowing gem authors to specify the ones that
    >>>> would make sense (as in sftp).
    >>> Thanks for answering, Chad. I'm working on this feature at the
    >>> moment.

    >
    >>> Robert and others: should it stub every file, or should gem authors
    >>> decide which files are to be stubbed?

    >> Chad and others: I think the latter solution is best; stubbing every
    >> file seems awkward and the author can influence what people expect to be
    >> stubbed in the docs etc. I wouldn't mind spec'ing it in the GemSpec.

    >
    > Why not offer both? That is, give the spec author a simple token that
    > can be detected to stub everything in the lib directory?
    >
    > -austin


    Well, because is rather defeats the purpose of keeping the files out of the
    site_ruby dir.

    -rich
    Richard Kilmer, Aug 17, 2004
    #8
  9. On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
    > > Why not offer both? That is, give the spec author a simple token that
    > > can be detected to stub everything in the lib directory?
    > >
    > > -austin

    >
    > Well, because is rather defeats the purpose of keeping the files out of the
    > site_ruby dir.


    Doesn't that happen from the very moment you create any stub? You can
    only have 1 version of the lib. in sitelibdir anyway.

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
    Mauricio Fernández, Aug 17, 2004
    #9
  10. > On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
    > > > Why not offer both? That is, give the spec author a simple token that
    > > > can be detected to stub everything in the lib directory?

    > > Well, because is rather defeats the purpose of keeping the files out of the
    > > site_ruby dir.


    Well ... what's to stop me from listing all of my lib/* files anyway?

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Aug 17, 2004
    #10
  11. On 8/17/04 10:04 AM, "Austin Ziegler" <> wrote:

    >> On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
    >>>> Why not offer both? That is, give the spec author a simple token that
    >>>> can be detected to stub everything in the lib directory?
    >>> Well, because is rather defeats the purpose of keeping the files out of the
    >>> site_ruby dir.

    >
    > Well ... what's to stop me from listing all of my lib/* files anyway?
    >
    > -austin


    Nothing stops you, but nothing forces you either. In most libraries, there
    is a main file to 'require' (which then requires the rest of the required
    files) and you document your library accordingly. At least, with the
    libraries I write, that is how I design them. I guess if your library was a
    random collection of a series of separate files that could individually be
    required or not, then stubbing every one would make some sense.
    Richard Kilmer, Aug 17, 2004
    #11
  12. On Tue, 17 Aug 2004 23:17:52 +0900, Richard Kilmer <> wrote:
    > On 8/17/04 10:04 AM, "Austin Ziegler" <> wrote:
    > >> On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
    > >>>> Why not offer both? That is, give the spec author a simple token that
    > >>>> can be detected to stub everything in the lib directory?
    > >>> Well, because is rather defeats the purpose of keeping the files out of the
    > >>> site_ruby dir.

    > > Well ... what's to stop me from listing all of my lib/* files anyway?

    > Nothing stops you, but nothing forces you either. In most libraries, there
    > is a main file to 'require' (which then requires the rest of the required
    > files) and you document your library accordingly. At least, with the
    > libraries I write, that is how I design them. I guess if your library was a
    > random collection of a series of separate files that could individually be
    > required or not, then stubbing every one would make some sense.


    Well, I can think of one library (Gavin's Extensions) library that is
    pretty much exactly that way.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Aug 17, 2004
    #12
  13. On 8/17/04 10:29 AM, "Austin Ziegler" <> wrote:

    > On Tue, 17 Aug 2004 23:17:52 +0900, Richard Kilmer <> wrote:
    >> On 8/17/04 10:04 AM, "Austin Ziegler" <> wrote:
    >>>> On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
    >>>>>> Why not offer both? That is, give the spec author a simple token that
    >>>>>> can be detected to stub everything in the lib directory?
    >>>>> Well, because is rather defeats the purpose of keeping the files out of
    >>>>> the
    >>>>> site_ruby dir.
    >>> Well ... what's to stop me from listing all of my lib/* files anyway?

    >> Nothing stops you, but nothing forces you either. In most libraries, there
    >> is a main file to 'require' (which then requires the rest of the required
    >> files) and you document your library accordingly. At least, with the
    >> libraries I write, that is how I design them. I guess if your library was a
    >> random collection of a series of separate files that could individually be
    >> required or not, then stubbing every one would make some sense.

    >
    > Well, I can think of one library (Gavin's Extensions) library that is
    > pretty much exactly that way.
    >
    > -austin


    Excellent...then a Dir.glob should do you well for that library.
    Richard Kilmer, Aug 17, 2004
    #13
  14. On Wednesday, August 18, 2004, 12:17:52 AM, Richard wrote:




    > On 8/17/04 10:04 AM, "Austin Ziegler" <> wrote:


    >>> On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
    >>>>> Why not offer both? That is, give the spec author a simple token that
    >>>>> can be detected to stub everything in the lib directory?
    >>>> Well, because is rather defeats the purpose of keeping the files out of the
    >>>> site_ruby dir.

    >>
    >> Well ... what's to stop me from listing all of my lib/* files anyway?
    >>
    >> -austin


    > Nothing stops you, but nothing forces you either. In most libraries, there
    > is a main file to 'require' (which then requires the rest of the required
    > files) and you document your library accordingly. At least, with the
    > libraries I write, that is how I design them. I guess if your library was a
    > random collection of a series of separate files that could individually be
    > required or not, then stubbing every one would make some sense.


    That _is_ the case in one of my libraries, but I reckon that's not
    often the case.

    It does happen reasonably often, though, that a library has several
    potential 'require' targets, some of which will never be loaded unless
    you ask for them. Rake's not a good example, because it's more an app
    that a library, but it's all that comes to mind at the moment:

    require 'rake'
    require 'rake/packagetask'
    require 'rake/rdoctask'
    # etc.

    Gavin
    Gavin Sinclair, Aug 17, 2004
    #14
  15. On 8/17/04 11:23 AM, "Gavin Sinclair" <> wrote:

    > On Wednesday, August 18, 2004, 12:17:52 AM, Richard wrote:
    >
    >
    >
    >
    >> On 8/17/04 10:04 AM, "Austin Ziegler" <> wrote:

    >
    >>>> On Tue, Aug 17, 2004 at 10:31:15PM +0900, Richard Kilmer wrote:
    >>>>>> Why not offer both? That is, give the spec author a simple token that
    >>>>>> can be detected to stub everything in the lib directory?
    >>>>> Well, because is rather defeats the purpose of keeping the files out of
    >>>>> the
    >>>>> site_ruby dir.
    >>>
    >>> Well ... what's to stop me from listing all of my lib/* files anyway?
    >>>
    >>> -austin

    >
    >> Nothing stops you, but nothing forces you either. In most libraries, there
    >> is a main file to 'require' (which then requires the rest of the required
    >> files) and you document your library accordingly. At least, with the
    >> libraries I write, that is how I design them. I guess if your library was a
    >> random collection of a series of separate files that could individually be
    >> required or not, then stubbing every one would make some sense.

    >
    > That _is_ the case in one of my libraries, but I reckon that's not
    > often the case.
    >
    > It does happen reasonably often, though, that a library has several
    > potential 'require' targets, some of which will never be loaded unless
    > you ask for them. Rake's not a good example, because it's more an app
    > that a library, but it's all that comes to mind at the moment:
    >
    > require 'rake'
    > require 'rake/packagetask'
    > require 'rake/rdoctask'
    > # etc.


    Right...and what is cool is if the stub is 'rake' then doing:

    require 'rake'

    Will move the rake gem into the LOAD_PATH so subsequent:

    require 'rake/packagetask'
    require 'rake/rdoctask'

    Just works, because rakes libs are now fully available (no stubs needed).

    -rich
    Richard Kilmer, Aug 17, 2004
    #15
  16. On Wednesday, August 18, 2004, 1:27:59 AM, Richard wrote:

    >>> I guess if your library was a random collection of a series of
    >>> separate files that could individually be required or not, then
    >>> stubbing every one would make some sense.

    >>
    >> That _is_ the case in one of my libraries, but I reckon that's not
    >> often the case.
    >>
    >> It does happen reasonably often, though, that a library has several
    >> potential 'require' targets, some of which will never be loaded unless
    >> you ask for them. Rake's not a good example, because it's more an app
    >> that a library, but it's all that comes to mind at the moment:
    >>
    >> require 'rake'
    >> require 'rake/packagetask'
    >> require 'rake/rdoctask'
    >> # etc.


    > Right...and what is cool is if the stub is 'rake' then doing:


    > require 'rake'


    > Will move the rake gem into the LOAD_PATH so subsequent:


    > require 'rake/packagetask'
    > require 'rake/rdoctask'


    > Just works, because rakes libs are now fully available (no stubs needed).


    Good point. Then there's just the corner case, where someone goes

    require 'rake/packagetask'

    thinking that "require 'rake'" is implicit in that, and getting a
    surprise.

    That's where the ability to stub lots of files is useful. And if the
    package author chooses which files to stub, instead of doing them
    all, it conveys to the user which files are "interesting".

    Gavin
    Gavin Sinclair, Aug 17, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tomás

    Gems -- #include <gems.hpp>

    Tomás, Mar 4, 2006, in forum: C++
    Replies:
    7
    Views:
    406
    Tomás
    Mar 5, 2006
  2. Lloyd Zusman
    Replies:
    3
    Views:
    164
    Lloyd Zusman
    Jun 21, 2005
  3. Dany Cayouette

    'private' gems/gems hierarchy

    Dany Cayouette, Nov 25, 2005, in forum: Ruby
    Replies:
    3
    Views:
    141
    Jim Weirich
    Nov 25, 2005
  4. Foolish Brat

    Fail to Install Gems - My First Gems

    Foolish Brat, Sep 1, 2007, in forum: Ruby
    Replies:
    4
    Views:
    141
    Eric Hodel
    Sep 10, 2007
  5. Max Williams
    Replies:
    12
    Views:
    306
    Max Williams
    Jul 13, 2008
Loading...

Share This Page