Rspec with warnings - ignore gems / whitelist directories

[Patrick Davey]

Hi,

I have just got around to reading "The Pragmatic Programmer", long past time, and one of the things it recommends is upping the warnings to the max and fixing the lot. This sounded like good advice. So I added --warnings to my .rspec and was swiftly flooded with a lot of warnings, quite a few from gems.

I was wondering, is it possible with rspec to whitelist my application for warnings. That is, I'd like to see any bad code that I have introduced, but not anyone else. If not, is this something which would be worth adding?

Thanks,
Patrick

[Myron Marston]

Yes, it's worth doing -- provided it can be done in a simple, robust, clean way.  I've made multiple attempts in the test suite of multiple projects over the years to build something that does this but have never found a solution that works well enough to include in RSpec itself.

RSpec itself doesn't provide any sort of warnings mode...the `--warnings` flag just turns on Ruby's warning mode and Ruby provides no way to filter warnings.  Warnings are emitted to stderr so to filter you have to intercept stderr output and find a way to filter it.  Problem is, there is no standard warning message format, so you can't count on any thing in particular (such as a gem name or file path) in the message to use to filter.  On top of that, stderr contains output from many other things so have to be careful to not accidentally silence other useful things.

Myron

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/98c930c3-da5b-4360-9c8a-085f1f9f48ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jon Rowe]

Could we combine the logic we use to filter backtraces with the code we use to detect warnings within our own specs and make something that could channel stderr through it and filter them?

Jon Rowe

---------------------------

ma...@jonrowe.co.uk

jonrowe.co.uk

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/CADUxQmsihH%3DAWv7Tb1BmaQovFm6W-GK%3DLHmfs5LWUgTLE0aA3w%40mail.gmail.com.

[Patrick Davey]

I guess the question  is, whether it's possible to filter the warnings in a way that is "simple, robust and clean" ?

If there is no standard to the deprecations, and if they just call warn, then (I guess?) there's no way to be sure you're not clobbering other stderr. The risk would be that people would forget they'd left the filtering on, and then miss subsequent warnings somehow. If an extra bit out output was added to the end of an rspec run (with filtered warnings enabled), which said something like "123 warnings have been filtered out", then at least the developer would be reminded that they still had filtering turned on.

It seems to me that there is no way to do this cleanly, as there is no way to be sure that you're not clobbering other uses of stderr based on what Myron said. So, is a whitelist and reminder to the developer that messages are being filtered a satisfactory approach?  It would, after all, be a feature that developers would have to knowingly opt in to, and they'd be doing it in order to keep their own code free of warnings.

I'm only a consumer of rspec, never having looked at the internals, but I'd be happy to try and get something working, assuming the approach was one which was going to be satisfactory.

[Myron Marston]

Could we combine the logic we use to filter backtraces with the code we use to detect warnings within our own specs and make something that could channel stderr through it and filter them?

I don't think our backtrace filtering logic could be applied to warnings filtering.  Backtraces have a standard form that _always_ includes the file name and is therefore easy to filter by file name or gem source.

Warnings, on the other hand, have no standard form and do not always include file names.

Another thing to bear in mind is that RSpec's `--warnings` flag is only intended to enable Ruby's warning mode -- which is an entirely different thing from warnings emitted by ruby code calling `$stderr.warn` but which is surfaced to the user in the same way (via $stderr).  It's not totally clear to me what kind of warnings you're intending to solve, Patrick.

Personally, I wish Ruby itself provided APIs to control warnings more tightly so that you could enable it for only particular files or directories.  Such an API could then trivially used in RSpec for this purpose and could be useful outside of RSpec, too. Patrick, would you want to work with the Ruby core team to see if they're interested in that kind of improvement?

If you want to proceed with working off of what Ruby currently provides, I recommend building it as an RSpec extension gem.  Once it has proved useful, robust and stable in multiple projects we can consider rolling it into RSpec in a future version.

Myron

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/4a795b08-1df5-40cf-bdb8-022e9a4bb9cd%40googlegroups.com.

[Patrick Davey]

Another thing to bear in mind is that RSpec's `--warnings` flag is only intended to enable Ruby's warning mode -- which is an entirely different thing from warnings emitted by ruby code calling `$stderr.warn` but which is surfaced to the user in the same way (via $stderr).  It's not totally clear to me what kind of warnings you're intending to solve, Patrick.

 

Heh, I'm not exactly sure either Myron ;) which may be an issue! Basically I just turned on rpsec's --warnings flag and was inundated with messages from other people's gems, and my first thought was that I'd like to be able to only see warnings which have been raised for code that I have written. That was the use case I was trying to fix.

 

Personally, I wish Ruby itself provided APIs to control warnings more tightly so that you could enable it for only particular files or directories.  Such an API could then trivially used in RSpec for this purpose and could be useful outside of RSpec, too. Patrick, would you want to work with the Ruby core team to see if they're interested in that kind of improvement?

There's a question. Yes I'd be interested, it'd be great to give back to the community. How would you propose starting? One possible good/bad thing is that I'm taking a year out at the moment (currently in Argentina), so having access to internet all the time isn't going to be that easy.  That, and my partner will kill me if I just code all the time ;)  hehe, but, yes, in principle I love the idea, just not sure where to start.
 

If you want to proceed with working off of what Ruby currently provides, I recommend building it as an RSpec extension gem.  Once it has proved useful, robust and stable in multiple projects we can consider rolling it into RSpec in a future version.

Yip, I might do that anyway, working to sort out an API with the core team might take a while anyway. I've had a quick look for a guide to writing an extension but didn't turn up anything immediate. Should I just look at how other user contributed gems work and go from there.

Many thanks for taking the time to respond, I hope I can put something together that's useful.

Patrick

 

[Myron Marston]

How would you propose starting?

I'd start by writing a gem that isn't RSpec specific.  Write a gem that can be loaded in any ruby program and configured to silence some warnings and allow others.  Then the gem is useful outside an RSpec context.  You can always include a small RSpec shim that integrates the gem with RSpec for convenience for RSpec users.