When Using Spring, Specs Won't Run Unless rspec Has Been Installed as a Spring Command

[sshaw]

This adds a check for the SPRING_DISABLE environment variable.

Also note that even though Spring was not running it still tried to execute spring rspec .... This resulted in Spring's usage.

[dgutov]

Can't it be set to a different non-empty value?

[sshaw]

Could be set to anything. How about I do this:

(member (getenv "SPRING_DISABLE") '(nil "" "0"))

Or this:

(or
  (null (getenv "SPRING_DISABLE"))
  (equal "" (getenv "SPRING_DISABLE"))
  (equal "0" (getenv "SPRING_DISABLE")))

[sshaw]

But where do we stop, should we also check for "false", "off", etc..?

[dgutov]

Does 0 mean "not disable"?

[sshaw]

Yes.

[dgutov]

I suppose so, then. Check all three of these possible values, using member.

It's doesn't seem like false, etc, should be treated similarly: https://github.com/rails/spring/blob/7efd492018049df43310feb89acbaf226446a123/lib/spring/binstub.rb

[dgutov]

And please fix the name of the variable (words in wrong order).

[dgutov]

Also note that even though Spring was not running it still tried to execute spring rspec ....

Maybe you had a .pid file left over? See rspec-spring-p.

[sshaw]

Also note that even though Spring was not running it still tried to execute spring rspec ....

Maybe you had a .pid file left over? See rspec-spring-p.

Sure, though have you considered using (process-live-p PID) or spring status? Of course these may be overkill...

[dgutov]

process-live-p doesn't take PID as argument.

[sshaw]

process-live-p doesn't take PID as argument.

Ah of course, a process object... 💨

[sshaw]

process-live-p doesn't take PID as argument.

There's always (memq PID (list-system-processes)). But I'm getting sidetracked...

[dgutov]

Hmm, actually, since setting this var makes Spring not do anything, why bother with it on our end?

[sshaw]

Hmm, actually, since setting this var makes Spring not do anything, why bother with it on our end?

If Spring's pid file is there but Spring is not running, then (rspec-verify) will run spring and the result will be its usage. So yes, the current approach is not correct, checking the pid would more suitable.

I can modify.

[dgutov]

If Spring's pid file is there but Spring is not running, then (rspec-verify) will run spring and the result will be its usage.

Please clarify: this is unrelated to DISABLE_SPRING, right?

What exactly happens? "Spring gets used" or "specs don't run"?

[sshaw]

If Spring's pid file is there but Spring is not running, then...
Please clarify: this is unrelated to DISABLE_SPRING, right?

Yes

What exactly happens? "Spring gets used" or "specs don't run"?

I don't normally use Spring so it was not obvious at first, but after doing some research it turns out that it fails when spring is running because rspec is not available as a spring command:

spring rspec --format documentation /Users/sshaw/code/ruby/txs/spec/models/source_spec.rb
Version: 1.3.6

Usage: spring COMMAND [ARGS]

Commands for spring itself:
...

You can only call spring rspec ... if rspec has been installed as a spring command.

[dgutov]

You can only call spring rspec ... if rspec has been installed as a spring command.

Ok. Do you think rspec-mode should do anything about that?

[sshaw]

Ok. Do you think rspec-mode should do anything about that?

The mode performs several checks in an effort to find the right option. It finds bundle exec -which would work fine, but it chooses to use spring -which doesn't. So yes, I think it should.

Maybe something like this:

(defun rspec-spring-p ()
  (and rspec-use-spring-when-possible
    (stuff-that-looks-up-spring-pid-file)
    (not (cl-notany (lambda (s) (string-match "^\s+rspec\s" s)) (process-lines "spring" "help")))))

[dgutov]

spring help takes half a second on my machine. Are you sure the certainty is worth the delay?

[sshaw]

spring help takes half a second on my machine. Are you sure the certainty is worth the delay?

Is saving 0.5 seconds worth the bug?

[dgutov]

Why not?

And if Spring is installed, not running specs through it is unlikely to be what the user wants. Rather, they want to be notified that spring-commands-rspec is required for that.

That could be done with a message at the bottom of the compilation buffer. Like rspec-handle-error currently does for another problem.

[sshaw]

Is saving 0.5 seconds worth the bug?

Why not?

(sigh) okay, let's agree that it is worth the bug.

And if Spring is installed, not running specs through it is unlikely to be what the user wants.

Maybe, maybe not. Is this what your experience has shown? Over the past 24 hours here are the problems I've had with spring + rspec:

1. specs ran with rspec pass and fail with spring rspec
2. spec fails, change a line, fails again, output shows old line
3. rspec-mode sometimes it runs bundle exec other times spring rspec

That could be done with a message at the bottom of the compilation buffer.

Certainly not a bad approach but, as you've said, it assumes that those using spring + rspec
always want to run spring rspec.

[dgutov]

Is this what your experience has shown?

Not really. I haven't used Rails for quite a while, so I haven't used Spring either. But you're the first to complain about it here.

it assumes that those using spring + rspec always want to run spring rspec

Why else would they be running Spring?

But anyway, they can avoid it by setting rspec-use-spring-when-possible to nil, for example. No need to spend those 0.5 seconds each time.

rspec-mode sometimes it runs bundle exec other times spring rspec

That's normal. IIRC, Spring performs bundle setup by itself.

[carlthuringer]

FWIW I also ran into this issue and after pondering and poking around at this for a little while, I realized that nobody on my team knows what spring is or what it's for. It was just cargo-culted in from rails new.

What we do know about and use is rspec, which is not included when you rails new. Actually since we're using rails and rspec, we use rspec-rails, then rails generate rspec:install. And that doesn't happen to add spring-commands-rspec to the bundle.

So I propose that this is a problem with rspec-rails, which should recognize that rails is distributing spring and that there's an integration necessary for full functionality: spring-commands-rspec.

Edit: the maintainer politely responded and closed as you can see:

Why doesn't rspec-rails add spring-commands-rspec as a development dependency and generate the stub after rails generate rspec:install?

Because spring is not a requirement of using rspec-rails or rails, in fact many of us advocate not using spring at all as it causes more problems than it fixes.