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
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
···
On Tue, 17 Aug 2004 06:47:26 +0900, Robert Feldt <feldt@ce.chalmers.se> 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
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".
···
On 8/16/04 5:47 PM, "Robert Feldt" <feldt@ce.chalmers.se> wrote:
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
···
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).
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.
On Tue, 17 Aug 2004 16:21:10 +0900, Robert Feldt <feldt@ce.chalmers.se> 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.
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
···
On Tue, 17 Aug 2004 16:21:10 +0900, Robert Feldt <feldt@ce.chalmers.se> 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.
Well, because is rather defeats the purpose of keeping the files out of the
site_ruby dir.
-rich
···
On 8/17/04 8:05 AM, "Austin Ziegler" <halostatue@gmail.com> wrote:
On Tue, 17 Aug 2004 16:21:10 +0900, Robert Feldt <feldt@ce.chalmers.se> 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?
Well ... what's to stop me from listing all of my lib/* files anyway?
-austin
···
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.
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.
···
On 8/17/04 10:04 AM, "Austin Ziegler" <halostatue@gmail.com> 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?
Well, I can think of one library (Gavin's Extensions) library that is
pretty much exactly that way.
-austin
···
On Tue, 17 Aug 2004 23:17:52 +0900, Richard Kilmer <rich@infoether.com> wrote:
On 8/17/04 10:04 AM, "Austin Ziegler" <halostatue@gmail.com> 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.
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
···
On Wednesday, August 18, 2004, 12:17:52 AM, Richard wrote:
On 8/17/04 10:04 AM, "Austin Ziegler" <halostatue@gmail.com> 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.
Excellent...then a Dir.glob should do you well for that library.
···
On 8/17/04 10:29 AM, "Austin Ziegler" <halostatue@gmail.com> wrote:
On Tue, 17 Aug 2004 23:17:52 +0900, Richard Kilmer <rich@infoether.com> wrote:
On 8/17/04 10:04 AM, "Austin Ziegler" <halostatue@gmail.com> 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.
Just works, because rakes libs are now fully available (no stubs needed).
-rich
···
On 8/17/04 11:23 AM, "Gavin Sinclair" <gsinclair@soyabean.com.au> wrote:
On Wednesday, August 18, 2004, 12:17:52 AM, Richard wrote:
On 8/17/04 10:04 AM, "Austin Ziegler" <halostatue@gmail.com> 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.
require 'rake'
require 'rake/packagetask'
require 'rake/rdoctask'
# etc.
Under normal circumstances, these requires go into a Rakefile, and since
rake is already running when the Rakefile is loaded, the require 'rake'
line isn't required ... even on a gems install.
If you are using the rake libraries outside of rake, then the answer is
different.
···
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
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
···
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: