spring doesn't pass command line args to rake 10.4.0

[modosc]

we're using spring-1.2.0 and we recently upgraded from rake-10.3.2 to rake-10.4.0. once this happened rake no longer recognized any command line arguments when called through spring (either spring rake -T or through the binstubs bin/rake -T). calling rake directly via bundle exec rake -T worked fine.

it looks like the newer version of rake altered the way it parses ARGV - i didn't spend a lot of time on this but perhaps that's where the problem lies?

ruby/rake@v10.3.2...v10.4.0#diff-09f3b4d91b5882a83d922ff0e061945dL730

[bellthoven]

Confirm!

I changed the line https://github.com/ruby/rake/blob/55e43d3da2e0c48ccc4dc5d09b999b0afb2467a5/lib/rake/application.rb#L80 to @argv = ARGV.dup and it works. Not sure how to properly fix it, thought

[bellthoven]

Assigning @argv = argv seems to assign the variable to is own value, since argv is the attr_reader. Is this a possible fix? /cc @drbrain

[drbrain]

I think that line needs to be deleted, I will fix it.

[drbrain]

How do I reproduce this issue so I can confirm a fix?

[modosc]

@drbrain all you need is a Rakefile with a default task. then bin/rake -T should print a task list instead of running the default task.

[drbrain]

What should happen when it is broken/fixed? I don't understand, this seems to work as expected:

$ echo 'desc "hello"; task :default do puts "hello" end' > Rakefile
$ rake 
hello
$ rake -T
rake default  # hello
$ rake -T default
rake default  # hello
$ rake --version
rake, version 10.4.0

[drbrain]

Hold on, I seem to have messed up my rake

[drbrain]

With the useless @argv = argv still present I get the above output with the above test Rakefile. What am I missing?

[modosc]

right now rake -T runs the default task because it's not parsing the command line options (this is the same thing as calling rake without any arguments). so if running rake -T via spring does what it's supposed to do then i expect you've fixed it.

[drbrain]

I don't have enough information to reproduce this. I tried the steps in the readme from my rake checkout:

$ cat Gemfile
source 'https://rubygems.org'

gem "spring"
$ bundle install
Using spring 1.2.0
Using bundler 1.7.4
Your bundle is complete!
Use `bundle show [gemname]` to see where a bundled gem is installed.
$ bundle exec spring binstub --all
Spring was unable to find your config/application.rb file. Your project root was detected at /Users/erichodel/Work/git/rake, so spring looked for /Users/erichodel/Work/git/rake/config/application.rb but it doesn't exist. You can configure the root of your application by setting Spring.application_root in config/spring.rb.
$ mkdir config
$ touch config/application.rb
$ bundle exec spring binstub --all
* bin/rake: spring inserted
* bin/rails: generated with spring
$ ruby -Ilib bin/rake -T test
rake test               # test      # Run the test suite
rake test:slow          # test      # Show bottom 25 tests wrt time
rake test:times[limit]  #           # Find the slowest unit tests
rake test_cmd           # test      # Print out the test command
rake test_deps          # test      # Show which test files fail when run a...

So it seems to work fine, but then I don't have a rails app so I'm unsure.

Can you give me a list of commands to run to reproduce this?

[bellthoven]

There is something weird about it.

I tried to bootstrap a new rails app (spring 1.2.0 and rake 10.4.0) and it does not happen.

But, upgrading my existing rails app, rake 10.4.0 fails even with spring 1.1.3. So the problem might be in the rake project.

[bellthoven]

I think ruby/rake#4 might be related

[ngauthier]

I'm seeing this too. I am also unable to create a clean reproduction. I will dig in more and let you know if I can reproduce. Maybe a third gem is involved?

There are differences in my binstubs with a fresh rails project, but when I make my binstubs the same I still see the error.

[ngauthier]

If I remove rake from my gemfile but still use rake 10.4.0 and spring 1.2.0 then the problem is gone and I can rake -T normally.

[jonleighton]

I have no particular information about this bug, but my guess is that:

• Something involved in the Rails boot-up in your applications is calling Rake.application
• Therefore the @argv value gets set/frozen
• Then when spring forks and loads bin/rake (which calls Rake.application.run) the ARGV has no effect

So I'd look for something calling Rake.application...

[ngauthier]

changing:

gem 'newrelic_rpm'

to

gem 'newrelic_rpm', require: false

fixes the problem. Gonna pinpoint a version and open an issue over there.

[ngauthier]

Also, generating a fresh rails app with spring, rake, and newrelic_rpm (all updated) reproduces the problem cleanly.

[jonleighton]

I think this should either be fixed in Spring or Rake, rather than newrelic_rpm. Otherwise some other gem which inadvertantly happens to call Rake.application (assuming that is indeed what newrelic_rpm is doing) will also bring back the problem and we'll be playing whack-a-mole.

[ngauthier]

Yeah sure. But if I can isolate the changes in newrelic_rpm I can confirm your theory on Rake.application.

[ngauthier]

Plus opening an issue over there just to link to this could be helpful.

[jonleighton]

Sounds good

[ngauthier]

Confirmed:

newrelic/newrelic-ruby-agent@466d621#diff-7ff14b640b9a1091a7870773cf8cbc0eR47

Is the breaking change.

Thank Linus for git bisect!

[jonleighton]

@drbrain Do you propose to fix this in Rake? Or perhaps Spring should call Rake.application = Rake::Application.new if Rake.application has already been set?

[ngauthier]

Example app:

https://github.com/ngauthier/spring-issue-366-example

If you bring that down and run:

bundle
rake
rake -T

The rake -T will run the default task. If you go into party-pooper/lib/party/pooper.rb and comment out the Rake.application line, the rake -T issue will be resolved.

Hope this helps.

[drbrain]

@ngauthier thanks! I'll check it out tonight

@jonleighton I consider this a regression in rake, I'll see if I can find a better way to fix the original bug.

[ngauthier]

Cool thanks. For other readers, the TLDR; quick fix is to lock rake at '~> 10.3.0'.

[drbrain]

rake 10.4.1 released so this can be closed once someone confirms. Thanks @ngauthier for the sample app.

[ngauthier]

Confirmed to fix, thanks for the quick turn around!

[rafaelfranca]

@drbrain ❤️ 💚 💙 💛 💜