<postmodern>
mbj, er rspec --tags which are passed in as metadata
<postmodern>
mbj, then you can define two separate spec tasks that use different tags
<dkubb>
oh yeah, I forgot about that
<dkubb>
can you have before blocks that execute depending on the tag? if so, then you could have conditional spec setup
<mbj>
Yeah I'm searching conditional spec setup
<dkubb>
maybe something like before :suite with a tag
<mbj>
But TBH passing key value pairs is not my ideal scenario
<dkubb>
mbj: you should ping @myronmarston on twitter
<mbj>
I'd love to pass a full config object in. And not call rspec from cli / rake task. Calling it from my build system.
<mbj>
postmodern: Anyways, string key value pairs could do the job, thx for your answer.
<dkubb>
mbj: it seems like the tag stuff is just for filtering, but I'm not sure
<mbj>
But I'll research on how to pass a config object, but I feel rspec design is not made for this.
<mbj>
see spec_helper.rb, it is not made to be called in a context.
<mbj>
rspec needs an overhaul here, IMHO.
<dkubb>
you could parse something yourself, and then set it in a local variable, and then set the metadata in a before :suite block
<dkubb>
actually, Rspec.configuration can be extended
<dkubb>
I've done it before
<dkubb>
I did something like: config.add_setting :time_now, default: Time.new(2013, 1, 1) in the RSpec.configure block
<mbj>
Yeah, problem is I'd like to do this outside of spec_helper.rb
<dkubb>
you can acess Rspec.configure anywhere
<mbj>
hah
<mbj>
thats it! Thx!
<dkubb>
:)
<mbj>
02:17 localtime, could not get this idea for myself. Appreciated!
<postmodern>
dkubb, how do you access the settings from other specs?
<postmodern>
dkubb, i usually define top-level constants, but that seems ugly
knowtheory has quit [Quit: Computer has gone to sleep]
therabidbanana has joined #rom-rb
mbj has quit [Ping timeout: 268 seconds]
<dkubb>
postmodern: in my case I wasn't accessing it in the specs, I had a config.around block in RSpec.configure I was accessing it in
<postmodern>
ah
<dkubb>
postmodern: I wouldn't be surprised if it defines something in the specs you can access. worst case you could get to it from RSpec.configuration.time_now
<dkubb>
I dunno if that's better or worse than constants
<dkubb>
I suppose you could have constants in a module and then use config.extend or config.include to bring it in to the spec
<dkubb>
or just bring in methods. I use that to share spec helper methods
therabidbanana has quit [Quit: leaving]
machuga is now known as machuga|away
theCrab has joined #rom-rb
xargoon_ has joined #rom-rb
stormwind has joined #rom-rb
stormwin1 has quit [*.net *.split]
xargoon has quit [*.net *.split]
machuga|away has quit [*.net *.split]
machuga has joined #rom-rb
xargoon_ is now known as xargoon
stormwin1 has joined #rom-rb
Guest69831 has joined #rom-rb
machuga has quit [*.net *.split]
stormwind has quit [*.net *.split]
theCrab has quit [Quit: Sleeping -_-]
ChanServ has quit [*.net *.split]
shingara has quit [*.net *.split]
kalleth has quit [*.net *.split]
indrek has quit [*.net *.split]
stormwin1 has quit [*.net *.split]
xybre has quit [*.net *.split]
kpwz has quit [*.net *.split]
Gibheer has quit [*.net *.split]
dbussink has quit [*.net *.split]
elskwid has quit [*.net *.split]
Guest69831 has quit [*.net *.split]
pdswan has quit [*.net *.split]
postmodern has quit [*.net *.split]
dkubb has quit [*.net *.split]
coxandrew has quit [*.net *.split]
xargoon has quit [*.net *.split]
coxandrew has joined #rom-rb
dkubb has joined #rom-rb
postmodern has joined #rom-rb
xargoon has joined #rom-rb
Guest69831 has joined #rom-rb
stormwin1 has joined #rom-rb
kpwz has joined #rom-rb
indrek has joined #rom-rb
elskwid has joined #rom-rb
ChanServ has joined #rom-rb
dbussink has joined #rom-rb
shingara has joined #rom-rb
pdswan has joined #rom-rb
kalleth has joined #rom-rb
Gibheer has joined #rom-rb
xybre has joined #rom-rb
Guest69831 is now known as machuga
machuga is now known as Guest40946
cox has joined #rom-rb
postmodern has quit [*.net *.split]
dkubb has quit [*.net *.split]
coxandrew has quit [*.net *.split]
dkubb has joined #rom-rb
postmodern has joined #rom-rb
theCrab has joined #rom-rb
zekefast has joined #rom-rb
namelessjon has joined #rom-rb
zekefast has quit [Quit: Leaving.]
Guest40946 is now known as machuga
mbj has joined #rom-rb
theCrab has quit [Read error: Operation timed out]
knowtheory has joined #rom-rb
mbj has quit [Ping timeout: 245 seconds]
zekefast has joined #rom-rb
zekefast has quit [Read error: Connection reset by peer]
<mbj>
dkubb: hola again, just synced with solnic we'll do a rom-style development workshop @eurucamp.
<mbj>
Still not had the time to read through adpater and other rom*
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
<dkubb>
mbj: awesome. it'll be nice to see what you guys do. are you recording anything?
<mbj>
dkubb: I know talks are recorded, dunno if they do this for workshops
<mbj>
dkubb: Plan is quite simple and optimized for minimum amount of preparation:
<mbj>
We start with an artificial example for each tool we use: flay/flog/reek/mutant/...
<mbj>
And explain the tool, now to call it, and how to "read" that information.
<mbj>
Once audience got the tools we move to rom-rb/* and ask audience to pick improvable problems
<mbj>
We'll prepare "spots" of improvable metrics before.
<mbj>
Most likely this will be some less core lib like inflecto, but this way we "train" potential contributors and do not have to hide behind "artificial" examples.
postmodern has joined #rom-rb
<dkubb>
ahh ok
<dkubb>
I would talk about how the threshold system is an improvement over simply reporting that tools like metric_fu does
<dkubb>
I know solnic doesn't agree all the time, and thinks that failing metrics should not cause the build to fail, but I'm convinced that's one of our advantages
<mbj>
Yeah, I think solnic likes it if we have a "first time contributor mode" :D Where he can focus on specs.
<mbj>
*he = contributor
<dkubb>
working locally I use rubocop, and I don't have it failing the build on problems because I don't know it well enough, but I've found that rubocop issues go unnoticed for a while then
<dkubb>
sometimes I look at an issue and find it was introduced a couple of days ago. with our other tools I don't have that issue
<mbj>
I'd love to see contributors that make a green PR and fucking up metrics. We can train contributors for metrics very fast.
<dkubb>
yeah, I have been training people to focus on getting the specs to pass first
<mbj>
I agree with solnic that metrics can scare new contributors away.
<mbj>
So we should have a low entry bar, but will not merge PR till metrics are perfect.
<dkubb>
the order of the tasks in rake ci are actually on purpose
<dkubb>
if you just follow through and fix the tasks as they are found you'll be fine
<mbj>
"low PR entry bar"
<mbj>
It is easier to get people doing a PR intially. Once we have the PR contributor is emotionally *bound* to his PR so we can bug him with metrics :D
<dkubb>
heh
<mbj>
dkubb: BTW that rspec thing turns out me hooking deep into rspec.
<dkubb>
actually, we should be able to make travis so it does different things on different branches
<dkubb>
oh yeah?
<mbj>
Rspec is so mutable :(
<dkubb>
:(
<dkubb>
ahh well, maybe we can influence rspec 3
<mbj>
you have a configuration object
<mbj>
that you configure
<mbj>
you know it it is Rspec.configure { |config| ... }
<dkubb>
or Rspec.configuration I think
<dkubb>
if you want to get/set stuff directly not using the dsl
<mbj>
Than once rspec runs, an ConfigurationOption object parsed from CLI updates this Configuration instance.
<mbj>
But that ConfigurationOption object only parses cli if you tell it to do so: