Guard::RSpec::Formatter::NotificationRSpec again

[firedev]

Hi,

I can't get rid of that annoying stuff in my specs. Added gem 'rspec-legacy_formatters' to my Gemfile, added --deprecation-out to Guardfile's :cmd, nothing helps. How can I deal with it? Thanks.

RSpec's reporter has already been initialized with #<IO:<STDERR>> as the deprecation stream,
so your change to `deprecation_stream` will be ignored. You should configure it earlier for it to
take effect, or use the `--deprecation-out` CLI option. 
(Called from /Users/pain/Sites/real/spec/rails_helper.rb:19:in `block in <top (required)>')

Deprecation Warnings:

The Guard::RSpec::Formatter::NotificationRSpec formatter uses the deprecated formatter interface
not supported directly by RSpec 3.  To continue to use this formatter you must install the
`rspec-legacy_formatters` gem, which provides support for legacy formatters or upgrade the
formatter to a compatible version.

Formatter added at: 
/Users/pain/.rbenv/versions/2.1.3/lib/ruby/gems/2.1.0/bundler/gems/rspec-core-21f84019dd87/exe/rspec:4:in `<top (required)>'


If you need more of the backtrace for any of these deprecations to
identify where to make the necessary changes, you can configure
`config.raise_errors_for_deprecations!`, and it will turn the
deprecation warnings into errors, giving you the full backtrace.

1 deprecation warning total

[charlotte-miller]

I had a similar issue... did you try giving --deprecation-out an argument?

--deprecation-out log/deprecation.log

[Fryie]

Having the same problem. Tried rspec-legacy_formatters and --deprecation-out (with an argument), nothing works.
I also tried specifying version: 3 in my Guardfile, but then the specs don't get run at all.

[e2]

@Fryie - could you create a repo reproducing the problem (and the exact commmand you're using)? I'm guessing there's a problem with how the child process is created (which is where the special formatter is used).

[cloudbring]

+1 I'm seeing it.

[e2]

@cloudbring - create a repo to reproduce this and I'll take a look

[davidrunger]

Might this be caused by/related to the spring-watcher-listen gem? For me, adding/removing that gem causes the Guard::RSpec::Formatter::NotificationRSpec deprecation warning to appear/not appear accordingly. Here is a repo that has raises the deprecation warning when running specs with guard: issue_two_eighty_eight. I put a few brief notes in the README.

I think it might be relevant that spring-watcher-listen requires a relatively old version of listen, listen ~> 1.0.

(p.s. I am a Rails newb and have, relatively speaking, no idea what I am talking about.)

[ghost]

Seeing this as well, even with the rspec-legacy_formatters gem. What is the Guard::RSpec::Formatter::NotificationRSpec and how do I disable it?

[ghost]

Disregard. Passing notification: false seems to have fixed the problem.

[saneshark]

bump, as this is still a very annoying issue.

[e2]

@saneshark - can you provide a repo to reproduce this?

[saneshark]

I believe @davidrunger already has one: https://github.com/davidrunger/issue_two_eighty_eight

[davidrunger]

tl;dr: As @bm5k discovered, you can avoid hitting this problematic line of code by providing a notification: false option in your Guardfile, e.g.:

guard :rspec, cmd: 'spring rspec', notification: false do
  # ...
end

This eliminates the deprecation warning in the demo repo that was linked to above.

---

I think that I figured out what the problem is, in my case, at least. The spring-watcher-listen gem has a dependency of listen 1.3.1. However, guard-rspec currently depends on guard (~> 2.1) which depends on listen (~> 2.1). Thus, it is not possible to install the latest version of guard-rspec when using spring-watcher-listen. Bundler seems to find that the most recent compatible version of guard-rspec that can be installed alongside spring-watcher-listen (and the other gems in my Gemfile) is guard-rspec 1.2.1 (released Jul 31, 2012). That ultimately brings us to this line of code in guard-rspec 1.2.1:

arg_parts << "-f Guard::RSpec::Formatter::Notification#{rspec_class}#{rspec_version == 1 ? ":" : " --out "}/dev/null"

which ultimately triggers the deprecation warning. It is because of the if @options[:notification] conditional 3 lines above that @bm5k 's fix solves the problem.

It seems that this problematic line of code was changed on Sep 29, 2012, in a commit titled "Remove RSpec 1.x support": 31e1be0#diff-11bf02294329a3c67809ed844af6ced0L95, and we only see this problem resurfacing now because of the dependency interaction with spring-watcher-listen that forces the use of a rather old version of guard-rspec.

Thanks for your work on this gem, @e2 !

[e2]

@davidrunger - awesome explanation, thanks!

I think I should patch the old version of guard-rspec to avoid that formatter if newer version of RSpec - and release a fix for the guard-rspec 1.x branch. And copy the new formatter from guard-rspec 2.x and use it if a newer version of RSpec is created.

Meanwhile, there's ongoing work to get spring using a newer version of listen: rails/spring-watcher-listen#1 (though this is waiting on other issues to be fixed, namely for Celluloid 0.16.1).

So there's both Listen 2.x support in Listen to finish and guard-rspec 1.x to fix (PRs welcome for the later, since I'm already working on the former).

Again - thanks for explaining!

[saneshark]

👍 as setting notification: false is not really a solution if you're using guard-rspec for red-green style testing.

[e2]

@saneshark - I agree with you 100%. I'm not sure I can Listen 2.x can happen for Spring, so I'll see if I can find time to patch this.

[e2]

I released guard-rspec 1.2.2 by backporting the new formatter from guard-rspec 4.x.

It should get rid of the deprecation problem until guard-rspec 4.x can be used with spring-watcher-listen.

[davidrunger]

Solves the problem for me. (For newbs like me: bundle update guard-rspec to bump to version 1.2.2). So awesome! 💫 ✨ 😄 Thanks again!!!