Recursive install-stub for gems?

[Robert Feldt]

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

 

[Chad Fowler]

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

 

[Richard Kilmer]

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".

 

[Gavin Sinclair]

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

 

[Robert Feldt]

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

 

[Chad Fowler]

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

 

[Austin Ziegler]

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

 

[Richard Kilmer]

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

 

[Mauricio Fernández]

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.

 

[Austin Ziegler]

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

-austin

 

[Richard Kilmer]

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.

 

[Austin Ziegler]

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

 

[Richard Kilmer]

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.

 

[Gavin Sinclair]

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

 

[Richard Kilmer]

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

 

[Gavin Sinclair]

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