This happens because we now load Spring after we set APP_PATH.

Prior to #39225, bundle exec spring binstub --all would inject code at the top of bin/rails to load Spring before setting APP_PATH. When bin/rails was executed, Spring would hijack the control flow, which ensured APP_PATH was set only once.

I think it would be reasonable to instead set APP_PATH in config/boot.rb, below the code that loads Spring. That should prevent setting APP_PATH twice, just as before. I would have to look into how that affects engines and plugins though, since they also have some APP_PATH-related code.

To be fair I'm more inclined to revert the spring changes. I don't think they simplify anything in our setup, maybe the requirement of generating the binstubs, but we can still simplify generating the binstubs without changing how and when spring is loaded.

I think the original intent of the Spring changes was to ensure that, if Spring is installed, the app is always loaded via Spring in development and test, and never loaded via Spring otherwise. (Perhaps DHH can confirm?) Loading Spring in config/boot.rb ensures that all commands do that, even if bundle exec spring binstub --all has not been run, and even for commands which bundle exec spring binstub --all does not apply to (i.e. custom bins).

Loading Spring in config/boot.rb ensures that all commands do that, even if bundle exec spring binstub --all has not been run, and even for commands which bundle exec spring binstub --all does not apply to (i.e. custom bins).

All boot.rb is doing right now is checking RAILS_ENV and we can do that in bin/rails. We can generate a bin/rails with all that code already and not call, or require to call, bundle exec spring binstub --all. But, if all we want is to not sprign in development and test this code should be in spring and not in Rails.

Custom bins don't work with the current setup anyway. Spring only works for the commands that are registered on it.