RSpec Configuration param yielded by RSpec.configure should have access to options #732

Closed
jasonkarns opened this Issue Nov 18, 2012 · 8 comments

Comments

Projects
None yet
4 participants
@jasonkarns

RSpec::Core::Configuration should have access to the ConfigurationOptions that are instantiated by the Runner.

I would like the ability to do some custom configuration within RSpec.configure based on command line options (or otherwise-set options).

@dchelimsky

This comment has been minimized.

Show comment Hide comment
@dchelimsky

dchelimsky Nov 18, 2012

Member

Can you give an example of what you might do? I wonder if there is some way to do it already.

Member

dchelimsky commented Nov 18, 2012

Can you give an example of what you might do? I wonder if there is some way to do it already.

@jasonkarns

This comment has been minimized.

Show comment Hide comment
@jasonkarns

jasonkarns Nov 18, 2012

My current need is to change the logging level used by our app to DEBUG when RSpec is in debug mode (-d/--debug).

As a hack, I did this instead: ObjectSpace.each_object(RSpec::Core::ConfigurationOptions).map{|co| co.options[:debug]}

My current need is to change the logging level used by our app to DEBUG when RSpec is in debug mode (-d/--debug).

As a hack, I did this instead: ObjectSpace.each_object(RSpec::Core::ConfigurationOptions).map{|co| co.options[:debug]}

@alindeman

This comment has been minimized.

Show comment Hide comment
@alindeman

alindeman Nov 18, 2012

Contributor

Maybe we could simply allow you to query the current state of debug on RSpec.configuration?

Contributor

alindeman commented Nov 18, 2012

Maybe we could simply allow you to query the current state of debug on RSpec.configuration?

@jasonkarns

This comment has been minimized.

Show comment Hide comment
@jasonkarns

jasonkarns Nov 18, 2012

That would work for this instance. But why go to the trouble of exposing one particular option when you can just as easily expose the ConfigurationOptions object? Just as no one foresaw the use case for accessing debug, we cannot foresee any other use cases for the multitude of other available options.

That would work for this instance. But why go to the trouble of exposing one particular option when you can just as easily expose the ConfigurationOptions object? Just as no one foresaw the use case for accessing debug, we cannot foresee any other use cases for the multitude of other available options.

@alindeman

This comment has been minimized.

Show comment Hide comment
@alindeman

alindeman Nov 18, 2012

Contributor

To me, I'm wary of exposing the fact that options were set from the command line when yielding to RSpec.configure: it seems like too much of an implementation detail.

Contributor

alindeman commented Nov 18, 2012

To me, I'm wary of exposing the fact that options were set from the command line when yielding to RSpec.configure: it seems like too much of an implementation detail.

@dchelimsky

This comment has been minimized.

Show comment Hide comment
@dchelimsky

dchelimsky Nov 18, 2012

Member

I'd rather move toward ensuring that all of the options are exposed on the Configuration than exposing another object.

Keep in mind the the ConfigurationOptions object may not have all of the options that are defined on the Configuration. Also, the rest of RSpec uses the Configuration object to make decisions, so it would be more consistent to go that route, IMO.

Member

dchelimsky commented Nov 18, 2012

I'd rather move toward ensuring that all of the options are exposed on the Configuration than exposing another object.

Keep in mind the the ConfigurationOptions object may not have all of the options that are defined on the Configuration. Also, the rest of RSpec uses the Configuration object to make decisions, so it would be more consistent to go that route, IMO.

@alindeman

This comment has been minimized.

Show comment Hide comment
@alindeman

alindeman Nov 18, 2012

Contributor

Agree.

Contributor

alindeman commented Nov 18, 2012

Agree.

@myronmarston

This comment has been minimized.

Show comment Hide comment
@myronmarston

myronmarston Apr 18, 2013

Member

Closing now that we've merged #834.

Member

myronmarston commented Apr 18, 2013

Closing now that we've merged #834.

myronmarston referenced this issue Aug 24, 2013

alternate exposing of config variables
Conflicts:
	lib/rspec/core/configuration.rb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment