RSpec excludes backtrace from working directory called "gems" #1604
Comments
|
I'd be ok with us relying on |
|
As of #843 (released in RSpec 2.14), there's also So there's something else going on here that I don't understand yet. We're also discussing removing the |
|
Could this be related to #1602? |
|
@radar -- to repro this, should we just clone your spree_poro repo into |
|
Yup, that's all! No particular SHA, master branch works well. On Sun, Jun 22, 2014 at 3:47 PM, Myron Marston notifications@github.com
|
|
Thanks @radar. I can repro this. @JonRowe -- I've tracked this regression down to your changes in #1329. When I checkout the version of |
|
Sure thing |
|
Yep so found the reason for this, we made system exclusions take priority over inclusions and so excludes over the inclusion of the working directory, a simple fix for this I think is to exclude the working directory from the lines matched against exclusion filters |
|
Thanks for taking a look at this @myronmarston and @JonRowe :) |
|
Yup, this works now. Thank you @myronmarston and @JonRowe :) |
This also greatly simplifies the backtrace formatter; the system_exclusion_patterns approach made it more complicated, as did always having an inclusion_pattern. We only need the current directory as an inclusion_pattern when it matches one of the built-in exclusion patterns. Note that this was the approach that we originally had in #843; it got lost in the refactoring in #1062 (af0b271). While it seemed like a simpler approach to always put the current dir in the inclusion_patterns, in practice, this caused a sequence of whack-a-mole regressions: - #1328 (fixed by #1329) - #1604 (fixed by #1616) - #1705 (fixed by this commit) I'm hopeful that returning to only including the current dir in `inclusion_patterns` if it matches a built-in exclusion pattern will solve these issues once and for all.
This also greatly simplifies the backtrace formatter; the system_exclusion_patterns approach made it more complicated, as did always having an inclusion_pattern. We only need the current directory as an inclusion_pattern when it matches one of the built-in exclusion patterns. Note that this was the approach that we originally had in #843; it got lost in the refactoring in #1062 (af0b271). While it seemed like a simpler approach to always put the current dir in the inclusion_patterns, in practice, this caused a sequence of whack-a-mole regressions: - #1328 (fixed by #1329) - #1604 (fixed by #1616) - #1705 (fixed by this commit) I'm hopeful that returning to only including the current dir in `inclusion_patterns` if it matches a built-in exclusion pattern will solve these issues once and for all.
This also greatly simplifies the backtrace formatter; the system_exclusion_patterns approach made it more complicated, as did always having an inclusion_pattern. We only need the current directory as an inclusion_pattern when it matches one of the built-in exclusion patterns. Note that this was the approach that we originally had in #843; it got lost in the refactoring in #1062 (af0b271). While it seemed like a simpler approach to always put the current dir in the inclusion_patterns, in practice, this caused a sequence of whack-a-mole regressions: - #1328 (fixed by #1329) - #1604 (fixed by #1616) - #1705 (fixed by this commit) I'm hopeful that returning to only including the current dir in `inclusion_patterns` if it matches a built-in exclusion pattern will solve these issues once and for all.
This also greatly simplifies the backtrace formatter; the system_exclusion_patterns approach made it more complicated, as did always having an inclusion_pattern. We only need the current directory as an inclusion_pattern when it matches one of the built-in exclusion patterns. Note that this was the approach that we originally had in rspec#843; it got lost in the refactoring in rspec#1062 (af0b271). While it seemed like a simpler approach to always put the current dir in the inclusion_patterns, in practice, this caused a sequence of whack-a-mole regressions: - rspec#1328 (fixed by rspec#1329) - rspec#1604 (fixed by rspec#1616) - rspec#1705 (fixed by this commit) I'm hopeful that returning to only including the current dir in `inclusion_patterns` if it matches a built-in exclusion pattern will solve these issues once and for all.
This also greatly simplifies the backtrace formatter; the system_exclusion_patterns approach made it more complicated, as did always having an inclusion_pattern. We only need the current directory as an inclusion_pattern when it matches one of the built-in exclusion patterns. Note that this was the approach that we originally had in rspec/rspec-core#843; it got lost in the refactoring in rspec/rspec-core#1062 (af0b271c92ad2a3336eb70be7bf2c0de4325a568). While it seemed like a simpler approach to always put the current dir in the inclusion_patterns, in practice, this caused a sequence of whack-a-mole regressions: - rspec/rspec-core#1328 (fixed by rspec/rspec-core#1329) - rspec/rspec-core#1604 (fixed by rspec/rspec-core#1616) - rspec/rspec-core#1705 (fixed by this commit) I'm hopeful that returning to only including the current dir in `inclusion_patterns` if it matches a built-in exclusion pattern will solve these issues once and for all. --- This commit was imported from rspec/rspec-core@9f53daf.
I have all my gems at a directory called
~/Projects/gems. I've done this for a couple of years now.When I started a new project yesterday using RSpec 3 (https://github.com/radar/spree_poro), I noticed that it was showing the entire backtrace, rather than excluding all the lines from RSpec and only showing the lines from my code.
I think this is due to
backtrace_exclusion_patternschecking for "gems" in the path, as seen here.I understand the reasons behind that line being there; it's just a way to blanket exclude all the code from the Ruby install's gem directory. I think this is fixable in one of two ways: 1) I rename my
gemsdirectory to something else less generic or 2) RSpec checks something equivalent togem envto find the "GEM PATHS" and excludes those directories.The text was updated successfully, but these errors were encountered: