require 'rubygems'

[David Chelimsky-2]

Hey all,

I'd like your feedback on something before I merge it into master.

Before the 1.2 release I read http://gist.github.com/54177, in which
Ryan Tomayko explains why "require 'rubygems'" should not appear in
your library code. This made some sense to me. So much so, that I
yanked it from rspec for the 1.2 release.

Then the bug reports started coming in and some conversation led me to
believe that this had been a mistake because it caused pain for the
lion's share of rspec users because most libraries go ahead and
require 'rubygems', so that has become the defacto standard situation,
for better or worse.

The solution that I added to 1.2.1 was to reinstate "require
'rubygems'" but with a catch:

  require 'rubygems' unless ENV['NO_RUBYGEMS']

This seemed like a fair tradeoff, since it allowed those who didn't
want to have to think about it to just use rspec as/is, and those who
do care and don't use rubygems in any given environment had an out.

I've just received another report about that decision, with a patch,
that offers what I think is a better solution:
https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more

I've pushed Tobias' patch to a require-rubygems branch for the moment.
I'm inclined to merge it into master, but this would the third release
in a row that makes changes to how rspec handles rubygems, and I want
it to be the last. So please let me know your thoughts, for or
against.

Thanks,
David
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Peter Fitzgibbons]

-1 on the push to master.

I agree with Tobias' synopsis.  I think though that there could be something better than letting anyone's library fail without proper libraries.  As troublesome as rubygems might be for some, it is clear when I get a rubygems-load error that I'm missing an install detail.  When I get a load error from require... WTH?  Maybe without rubygems I'd expect any load error to be something "I" missed.

David, you may have stumbled upon a wakeup call to many rspec users who have not been paying attention to their library loading mechanism.  To any of those in pain... ever used PERL?  Shove THAT in your load library!  Ruby is sane in comparison.

So, rant and vote all in one.  A two in one deal!

Happy Trails

Peter Fitzgibbons
[phone]
Email: peter.fitzgibbons@...
IM GTalk: peter.fitzgibbons
IM Yahoo: pjfitzgibbons
IM MSN: pjfitzgibbons@...
IM AOL: peter.fitzgibbons@...

On Wed, Mar 25, 2009 at 8:31 PM, David Chelimsky <dchelimsky@...> wrote:

Hey all,

I'd like your feedback on something before I merge it into master.

Before the 1.2 release I read http://gist.github.com/54177, in which
Ryan Tomayko explains why "require 'rubygems'" should not appear in
your library code. This made some sense to me. So much so, that I
yanked it from rspec for the 1.2 release.

Then the bug reports started coming in and some conversation led me to
believe that this had been a mistake because it caused pain for the
lion's share of rspec users because most libraries go ahead and
require 'rubygems', so that has become the defacto standard situation,
for better or worse.

The solution that I added to 1.2.1 was to reinstate "require
'rubygems'" but with a catch:

 require 'rubygems' unless ENV['NO_RUBYGEMS']

This seemed like a fair tradeoff, since it allowed those who didn't
want to have to think about it to just use rspec as/is, and those who
do care and don't use rubygems in any given environment had an out.

I've just received another report about that decision, with a patch,
that offers what I think is a better solution:
https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more

I've pushed Tobias' patch to a require-rubygems branch for the moment.
I'm inclined to merge it into master, but this would the third release
in a row that makes changes to how rspec handles rubygems, and I want
it to be the last. So please let me know your thoughts, for or
against.

Thanks,
David
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Jim Weirich-2]

On Mar 26, 2009, at 1:31 AM, David Chelimsky wrote:

>  require 'rubygems' unless ENV['NO_RUBYGEMS']

This is what I use in Rake:

begin
   require 'rake'
rescue LoadError
   require 'rubygems'
   require 'rake'
end

Try without rubygems, then if it fails, try again with rubygems.

--
-- Jim Weirich
-- jim.weirich@...

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Scott Taylor-7]

David Chelimsky wrote:

> Hey all,
>
> I'd like your feedback on something before I merge it into master.
>
> Before the 1.2 release I read http://gist.github.com/54177, in which
> Ryan Tomayko explains why "require 'rubygems'" should not appear in
> your library code. This made some sense to me. So much so, that I
> yanked it from rspec for the 1.2 release.
>
> Then the bug reports started coming in and some conversation led me to
> believe that this had been a mistake because it caused pain for the
> lion's share of rspec users because most libraries go ahead and
> require 'rubygems', so that has become the defacto standard situation,
> for better or worse.
>
> The solution that I added to 1.2.1 was to reinstate "require
> 'rubygems'" but with a catch:
>
>   require 'rubygems' unless ENV['NO_RUBYGEMS']
>  

How are others normally loading libraries without rubygems?  Are most
writing wrapper scripts or setting the RUBYOPT environment variable as
Ryan points out in his post?

Scott

> This seemed like a fair tradeoff, since it allowed those who didn't
> want to have to think about it to just use rspec as/is, and those who
> do care and don't use rubygems in any given environment had an out.
>
> I've just received another report about that decision, with a patch,
> that offers what I think is a better solution:
> https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more
>
> I've pushed Tobias' patch to a require-rubygems branch for the moment.
> I'm inclined to merge it into master, but this would the third release
> in a row that makes changes to how rspec handles rubygems, and I want
> it to be the last. So please let me know your thoughts, for or
> against.
>
> Thanks,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>  

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[David Chelimsky-2]

On Wed, Mar 25, 2009 at 9:50 PM, Jim Weirich <jim.weirich@...> wrote:

>
> On Mar 26, 2009, at 1:31 AM, David Chelimsky wrote:
>
>>  require 'rubygems' unless ENV['NO_RUBYGEMS']
>
> This is what I use in Rake:
>
> begin
>  require 'rake'
> rescue LoadError
>  require 'rubygems'
>  require 'rake'
> end
>
> Try without rubygems, then if it fails, try again with rubygems.

That's essentially what's happening in this branch, though it's
wrapped in a method to reduce duplication.

One question I have about this approach is the impact it has on
someone who doesn't have the gem installed. Unlikely with rake, but
with something like diff-lcs, which rspec uses *if* you ask it to
present results with diffs, it is more likely. So:

begin
 require 'diff-lcs'
rescue LoadError
 require 'rubygems'
 require 'diff-lcs'
end

If I don't have diff-lcs installed, now rubygems will be loaded. Is
that a situation that would screw up those among us who use an
alternative gem management system? Or does that matter, since they're
trying to use something they don't have installed either way.

Sorry if this all seems pedantic. I just want to get this right.

Cheers,
David

>
> --
> -- Jim Weirich
> -- jim.weirich@...
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[David Chelimsky-2]

On Wed, Mar 25, 2009 at 9:56 PM, Scott Taylor <scott@...> wrote:

> David Chelimsky wrote:
>>
>> Hey all,
>>
>> I'd like your feedback on something before I merge it into master.
>>
>> Before the 1.2 release I read http://gist.github.com/54177, in which
>> Ryan Tomayko explains why "require 'rubygems'" should not appear in
>> your library code. This made some sense to me. So much so, that I
>> yanked it from rspec for the 1.2 release.
>>
>> Then the bug reports started coming in and some conversation led me to
>> believe that this had been a mistake because it caused pain for the
>> lion's share of rspec users because most libraries go ahead and
>> require 'rubygems', so that has become the defacto standard situation,
>> for better or worse.
>>
>> The solution that I added to 1.2.1 was to reinstate "require
>> 'rubygems'" but with a catch:
>>
>>  require 'rubygems' unless ENV['NO_RUBYGEMS']
>>
>
> How are others normally loading libraries without rubygems?  Are most
> writing wrapper scripts or setting the RUBYOPT environment variable as Ryan
> points out in his post?

The problem w/ RUBYOPT is that it means that rubygems is always loaded
even if you don't need it. At least that's the problem that's been
expressed to me. I don't have a problem with that myself because
pretty much everything I do depends on other gems.

FWIW,
David

>
> Scott
>
>
>> This seemed like a fair tradeoff, since it allowed those who didn't
>> want to have to think about it to just use rspec as/is, and those who
>> do care and don't use rubygems in any given environment had an out.
>>
>> I've just received another report about that decision, with a patch,
>> that offers what I think is a better solution:
>>
>> https://rspec.lighthouseapp.com/projects/5645/tickets/763-rubygems-handling-once-more
>>
>> I've pushed Tobias' patch to a require-rubygems branch for the moment.
>> I'm inclined to merge it into master, but this would the third release
>> in a row that makes changes to how rspec handles rubygems, and I want
>> it to be the last. So please let me know your thoughts, for or
>> against.
>>
>> Thanks,
>> David
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@...
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Mike Vincent]

On Wed, Mar 25, 2009 at 9:50 PM, Jim Weirich <jim.weirich@...> wrote:

>
> On Mar 26, 2009, at 1:31 AM, David Chelimsky wrote:
>
>>  require 'rubygems' unless ENV['NO_RUBYGEMS']
>
> This is what I use in Rake:
>
> begin
>  require 'rake'
> rescue LoadError
>  require 'rubygems'
>  require 'rake'
> end
>
> Try without rubygems, then if it fails, try again with rubygems.

I always liked a similar idiom using retry since the require will
return true the first time it's successful

begin
  require 'rake'
rescue LoadError
  retry if require 'rubygems'
end
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Mark Wilden]

I think this whole thing is a tempest in a teapot.

What are the actual, real-world disadvantages of "require 'rubygems'"?
Here's what Ryan says:

  Why You Shouldn't Force Rubygems On People
  ------------------------------------------
  When I use your library, deploy your app, or run your tests I may not want
  to use rubygems. When you "require 'rubygems'" in your code, you remove my
  ability to make that decision. I cannot unrequire rubygems, but you can
  not require it in the first place.

This sounds like more of a libertarian/philosophical rationale than
something that I should spend any time worrying about.

So require rubygems or don't require it - it doesn't matter to me (or
anyone I know) because I have rubygems installed. So do 99% of Rails
users, I'm willing to bet.

As for frequent releases, I don't think there's anything wrong with
that. That's the agile way - you release something, see what the
reaction is, change it, lather, maybe get soap in your eyes, rinse,
and repeat. No one's going to remember version 1.2.326 in six months,
anyway.

///ark

(Anyone figure out why there are so many Ryans on Rails?)
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[David Chelimsky-2]

On Wed, Mar 25, 2009 at 11:09 PM, Mark Wilden <mark@...> wrote:

> I think this whole thing is a tempest in a teapot.
>
> What are the actual, real-world disadvantages of "require 'rubygems'"?
> Here's what Ryan says:
>
>  Why You Shouldn't Force Rubygems On People
>  ------------------------------------------
>  When I use your library, deploy your app, or run your tests I may not want
>  to use rubygems. When you "require 'rubygems'" in your code, you remove my
>  ability to make that decision. I cannot unrequire rubygems, but you can
>  not require it in the first place.
>
> This sounds like more of a libertarian/philosophical rationale than
> something that I should spend any time worrying about.
>
> So require rubygems or don't require it - it doesn't matter to me (or
> anyone I know) because I have rubygems installed. So do 99% of Rails
> users, I'm willing to bet.

FWIW, I actually think he's got a legitimate point. It's one thing to
make things easier for the majority, but it's another to tie the hands
of the minority in the process. We should find a way to do it that
keeps options open for alternatives.

> As for frequent releases, I don't think there's anything wrong with
> that. That's the agile way - you release something, see what the
> reaction is, change it, lather, maybe get soap in your eyes, rinse,
> and repeat. No one's going to remember version 1.2.326 in six months,
> anyway.

You haven't been using rspec that long, have you :) History proves
that I have NO problem with frequent releases.

What I do have a problem with is saying "A, no, now B, now back to A,
oops - let's try "C" - all around one issue that has an impact on
users.

>
> ///ark
>
> (Anyone figure out why there are so many Ryans on Rails?)

How about all the ///arks?

Cheers,
David

> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Mark Wilden]

On Wed, Mar 25, 2009 at 9:33 PM, David Chelimsky <dchelimsky@...> wrote:
>
> FWIW, I actually think he's got a legitimate point. It's one thing to
> make things easier for the majority, but it's another to tie the hands
> of the minority in the process. We should find a way to do it that
> keeps options open for alternatives.

I don't disagree with that. If there's a solid idiom for accomodating
these users, you might as well add the three or four lines of code it
takes to make them happy. I was really just commenting on the
vehemence of the viewpoint, that it seemed to me was unsubstantiated
by any pragmatic (as opposed to political) concern.

However, there's not going to be any hands-tieing either way. Forking
a library, or even simply editing it in situ, is not the end of the
world. But I'd be interested to know just how many users there are out
there who haven't installed ruby-gems (including Ryan).

> What I do have a problem with is saying "A, no, now B, now back to A,
> oops - let's try "C" - all around one issue that has an impact on
> users.

Hey, I do that all the time with my users. :) RSpec admittedly does
have a somewhat larger installed base.

///ark
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Jim Weirich-2]

On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote:

> That's essentially what's happening in this branch, though it's
> wrapped in a method to reduce duplication.

Duplication?  How many places need to do this?

Seems to me that any libraries don't need this.  By the time the  
libraries are loading, rubygems should already be loaded (otherwise  
the libraries wouldn't have been found).

I only put this in the top level application code.  One place.

At least this is true for rake.  Is rspec different?

--
-- Jim Weirich
-- jim.weirich@...

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Peter Fitzgibbons]

On Thu, Mar 26, 2009 at 3:08 AM, Jim Weirich <jim.weirich@...> wrote:

On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote:

That's essentially what's happening in this branch, though it's
wrapped in a method to reduce duplication.

Duplication?  How many places need to do this?

Seems to me that any libraries don't need this.  By the time the libraries are loading, rubygems should already be loaded (otherwise the libraries wouldn't have been found).

I only put this in the top level application code.  One place.

At least this is true for rake.  Is rspec different?

I'm with you.  Also this seems to also be taken care of through RUBYOPT, no?


Peter Fitzgibbons
Email: peter.fitzgibbons@...

 

--

-- Jim Weirich
-- jim.weirich@...

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[David Chelimsky-2]

On Thu, Mar 26, 2009 at 4:08 AM, Jim Weirich <jim.weirich@...> wrote:

>
> On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote:
>
>> That's essentially what's happening in this branch, though it's
>> wrapped in a method to reduce duplication.
>
> Duplication?  How many places need to do this?
>
> Seems to me that any libraries don't need this.  By the time the libraries
> are loading, rubygems should already be loaded (otherwise the libraries
> wouldn't have been found).
>
> I only put this in the top level application code.  One place.
>
> At least this is true for rake.  Is rspec different?

There are several cases of libraries that rspec only needs to load
with certain command line options. These libraries get loaded by
rspec's options before any of *your* files are loaded, so even if you
require 'rubygems' from a spec_helper it won't happen until after we
need those files. We could, of course, change that strategy to reduce
this duplication, but that would require a fair bit more re-thinking
than needs happen before this issue is decided.

>
> --
> -- Jim Weirich
> -- jim.weirich@...
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[David Chelimsky-2]

2009/3/26 Peter Fitzgibbons <peter.fitzgibbons@...>:

>
> On Thu, Mar 26, 2009 at 3:08 AM, Jim Weirich <jim.weirich@...> wrote:
>>
>> On Mar 26, 2009, at 3:04 AM, David Chelimsky wrote:
>>
>>> That's essentially what's happening in this branch, though it's
>>> wrapped in a method to reduce duplication.
>>
>> Duplication?  How many places need to do this?
>>
>> Seems to me that any libraries don't need this.  By the time the libraries
>> are loading, rubygems should already be loaded (otherwise the libraries
>> wouldn't have been found).
>>
>> I only put this in the top level application code.  One place.
>>
>> At least this is true for rake.  Is rspec different?
>
> I'm with you.  Also this seems to also be taken care of through RUBYOPT, no?

Setting RUBYOPT means that all of your programs always load the
rubygems machinery even if you're not using rubygems. While I realize
that most of us use gems in nearly all (if not 100%) of our projects,
I think there is a case for saying "don't make me load rubygems unless
I need it" that is equally as strong as "don't force me to use
rubygems as my gem-loading strategy."

David

>
>
> Peter Fitzgibbons
> Email: peter.fitzgibbons@...
>
>
>>
>> --
>> -- Jim Weirich
>> -- jim.weirich@...
>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@...
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Peter Fitzgibbons]

On Thu, Mar 26, 2009 at 6:12 AM, David Chelimsky <dchelimsky@...> wrote:

2009/3/26 Peter Fitzgibbons <peter.fitzgibbons@...>:

>
>>
>> Seems to me that any libraries don't need this.  By the time the libraries
>> are loading, rubygems should already be loaded (otherwise the libraries
>> wouldn't have been found).
>>
>> I only put this in the top level application code.  One place.
>>
>> At least this is true for rake.  Is rspec different?
>
> I'm with you.  Also this seems to also be taken care of through RUBYOPT, no?

Setting RUBYOPT means that all of your programs always load the
rubygems machinery even if you're not using rubygems. While I realize
that most of us use gems in nearly all (if not 100%) of our projects,
I think there is a case for saying "don't make me load rubygems unless
I need it" that is equally as strong as "don't force me to use
rubygems as my gem-loading strategy."

Yes, I agree.  My arrow missed the target.  I was trying to say, those who need rubygems, as Ryan points out, should be using RUBYOPT or calling require 'rubygems' somewhere above "any" library.  I'm with Ryan that as a maintainer, you should be "above" the use of rubygems (as a rails user, I also understand the pain that entails).


Peter Fitzgibbons
Email: peter.fitzgibbons@...

David

>
>
> Peter Fitzgibbons
> Email: peter.fitzgibbons@...
>
>
>>
>> --
>> -- Jim Weirich
>> -- jim.weirich@...
>>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Tobias Grimm]

Mark Wilden wrote:

So require rubygems or don't require it - it doesn't matter to me (or
anyone I know) because I have rubygems installed. So do 99% of Rails
users, I'm willing to bet.

You're right. But there are scenarios, where rubygems just is not needed. From a Debian Developers point of view, there is no reason for most packaged Ruby applications or libs to depend on rubygems, because any dependencies must be available as a Debian package anyway. It's not a problem to just strip the "require 'rubygems'" in the Debian package, but I prefer to push such changes upstream. My patch that David put into the require-rubygems branch, is just a compromise - load a library if available, if no try it with rubygems. (But I prefer Mike's proposal with the "retry" statement - haven't thought of this one...)

In general and from a software developers point of view, I don't think RSpec should require rubygems anywhere in it's libraries (!) at all! RSpec needs heckle and diff-lcs, not rubygems. RSpec shouldn't be aware from where and how external libraries it doesn't ship need to be loaded. This is an end-user issue and should be dealed with at the end-user level. This means RUBYOPTS or the bin/spec executable.

Just my two cent....

Tobias

[Joaquin Rivera Padron]

I might be wrong, but ain't that in Ruby 1.9 the require rubygems will be done by ruby itself?

also, are RSpec gems ready to use other options than rubygems (minigems I guess is a faster choice around there)?

cheers,
joaquin


_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Luis Lavena]

2009/3/26 Peter Fitzgibbons <peter.fitzgibbons@...>:

>
> On Thu, Mar 26, 2009 at 6:12 AM, David Chelimsky <dchelimsky@...>
> wrote:
>>
>> 2009/3/26 Peter Fitzgibbons <peter.fitzgibbons@...>:
>> >
>> >>
>> >> Seems to me that any libraries don't need this.  By the time the
>> >> libraries
>> >> are loading, rubygems should already be loaded (otherwise the libraries
>> >> wouldn't have been found).
>> >>
>> >> I only put this in the top level application code.  One place.
>> >>
>> >> At least this is true for rake.  Is rspec different?
>> >
>> > I'm with you.  Also this seems to also be taken care of through RUBYOPT,
>> > no?
>>
>> Setting RUBYOPT means that all of your programs always load the
>> rubygems machinery even if you're not using rubygems. While I realize
>> that most of us use gems in nearly all (if not 100%) of our projects,
>> I think there is a case for saying "don't make me load rubygems unless
>> I need it" that is equally as strong as "don't force me to use
>> rubygems as my gem-loading strategy."
>
> Yes, I agree.  My arrow missed the target.  I was trying to say, those who
> need rubygems, as Ryan points out, should be using RUBYOPT or calling
> require 'rubygems' somewhere above "any" library.  I'm with Ryan that as a
> maintainer, you should be "above" the use of rubygems (as a rails user, I
> also understand the pain that entails).
>

RUBYOPT is not the solution. I've faced and replied to lot (more than
20) emails and support requests about RUBYOPT being set or not in
One-Click Installer.

Also, the change of no rubygems all across rspec broke color output
when called form autospec, that is because it calls directly to ruby
with the direct binary script, not using RubyGems load machinery.

So, while I can agree with Ryan point on having rubygems in your
library or specs is wrong, sometimes is needed.

Extreme purism is not a solution. If someone is complaining on
something I'm doing wrong, please provide me a patch that doesn't
break my normal usage (or other hundred users).

Is hard to split between rspec and the libraries it depends on, even
harder for the user to trace what happened between the version of your
library that supposed to be working on previous releases.

Sorry for being so stubborn.

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Peter Fitzgibbons]

David,

Just want to point out, if you didn't think of it already (I'm expecting you did)

activesupport-2.3.2/lib/active_support/core_ext/kernel.rb#require_library_or_gem

looks like a nice complete example.  I am not suggesting dependency on activesupport... more stealing a well-honed example.

Regards,

Peter Fitzgibbons
[phone]
Email: peter.fitzgibbons@...
IM GTalk: peter.fitzgibbons
IM Yahoo: pjfitzgibbons
IM MSN: pjfitzgibbons@...
IM AOL: peter.fitzgibbons@...


_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel