Gem::LoadError: You have already activated rack-cors 1.0.1, but your Gemfile requires rack-cors 1.0.2 #4849
Comments
|
Thank you for the repro repo! I'm going to have a look now. |
|
I have successfully reproduced the issue on JRuby 9.1 HEAD. |
|
Ok, so the first obvious issue here is that when it restarts, it's not running bundle exec. The error message is right! 😁 Based on that, you can use the following puma configuration to tell it to do the right thing, and then the server restarts gracefully: diff --git a/config/puma.rb b/config/puma.rb
new file mode 100644
index 0000000..ef54432
--- /dev/null
+++ b/config/puma.rb
@@ -0,0 +1 @@
+restart_command "bundle exec bundler_bug_app_server"Now, if I log what MRI does, I get a similar command line for the subprocess: But running this command line does not work: JRuby and MRI follow different paths in restarting that do different things. I am going to look at the ENV to see what differs. |
|
I suspect this never worked right with any environment that needs |
|
*correction...I suspect this version of bundler probably doesn't work on any JRuby version when the app needs |
|
Inspecting ENV did not yield anything obvious. My chruby-based MRI env has GEM_ROOT and friends set, but that should not make much difference. Both envs had RUBYOPT set to Now the really baffling part: it suddenly started working for me locally. 😕 |
|
Ok, nevermind...I had rack-cors back at 1.0.1. |
|
Ah-ha! So it looks like if I run the bare JRuby command with This makes me think perhaps the RUBYOPT env is not propagating to the new process. |
|
Ok, it does seem to be some problem with propagating the RUBYOPT variable to the new process. If I provide it as an env on the command line it works: It also works with bundle exec if I set RUBYOPT at that point: My suspicion is that because the JRuby restart logic uses a direct call to |
|
Sometimes, the dumbest bugs take the most effort to find. This line works: This line doesn't: Don't strain yourself...the only difference is that RUBYOPT in the second case has whitespace as the first character. My guess is that we're tokenizing the string and since the first token before the first space is a blank string, we figure we're done. |
|
Closing the circle on my env theory: I had forgotten that by default, for the main JRuby instance in a given JVM we do actually set the real env. The |
|
Thanks a lot for that @headius! 👏 👏 👏 Much appreciated! I feel silly now, should have included the ENV dumps (which I did look at indeed, but I didn't spot the difference between:
and
I looked at the Puma code now briefly and this code there is causing the issue: https://github.com/puma/puma/blob/70f309b0260815ce5dec5faacf7e51cc742f0dd5/lib/puma/launcher.rb#L171 It means that the RUBYOPT will indeed have a leading space, which got us confused in the first place. It's good to have this fixed in JRuby core, but I will also file a Puma PR to avoid this at the source as well: puma/puma#1455 Sorry to ask, but when do you anticipate the 9.1.15.0 fix to be released? (We can use an older Bundler for now, but I assume it means we also have to use 9.1.13.0 since 9.1.14.0 has the newer bundler version built-in, which triggers this.) |
The problem is this:
```
2.4.2 :001 > [nil, 'foo'].join(' ')
=> " foo"
```
Note the leading space character. By `lstrip`:ing the result of the join, we avoid this altogether.
(This is a fix for the underlying problem that triggered jruby/jruby#4849.)
|
Tomorrow soon enough?
…On Thu, Dec 7, 2017, 03:52 Per Lundberg ***@***.***> wrote:
@headius <https://github.com/headius> @enebo <https://github.com/enebo>
How about releasing 9.1.15.0 soon? ❤️ 😉
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4849 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAnl6Yy-sxl5vYrYk--rLjxEuV1akcVks5s97VPgaJpZM4QZSmf>
.
|
Tomorrow is great! 🎉 |
|
For the record: Fixed in http://jruby.org/2017/12/07/jruby-9-1-15-0.html Thanks for your hard & great work @headius! 👍 |
Cross post of rubygems/bundler#6164, since the problem only occurs on JRuby. It seems remotely similar to #4740, so it could be the same root cause.
I have only reproduced it so far on macOS, but I'm quite certain that it's not OS specific in that sense.
This is similar to rubygems/bundler#6144 in that it's also related to
bundler/setupsomehow, but slightly different.Preconditions:
bundlerThe executable runs a few lines like this on startup:
This works well, both with bundler 1.15.4, 1.16.0 and so forth. But, we are utilizing self-restarts with puma and here we are seeing issues. When the process is restarted,
bundlerchooses the wrong gems and this breaks everything:I knew this is a tricky problem so I put together an extensive repro repo to be able to debug this in a reasonable way: https://github.com/perlun/bundler-1.16-bug
What I've concluded so far:
bundler 1.15.4seems to work correctly, even thought I have on a rare occasion seen it there (but later when testing, the bug usually goes away by downgrading to 1.15.4).bundler 1.16.0exhibits the problem.I will gladly assist in debugging this of course. My repro repo contains extensive instructions on how to trigger the problem. If you need more info or details, just let me know. I did look at the ENV variables in the "first" and "second" startups, but they didn't give me that much; all relevant RUBYOPT and BUNDLER_* variables were identical on both startups.
However, I did see something strange: on the first run, it used the executable from my "own" repo and in the second run, it used the executable from an installed gem version. This only happened in my private GitHub repo, in the repro repo it always used the executable from an installed gem version for whatever reason.
The text was updated successfully, but these errors were encountered: