On 0.3.0 - LoadError: no such file to load -- thread_safe/jruby_cache_backend #40
Comments
|
Yes, I'm having this issue as well. |
|
Ugh. I was sure it built the jar this time too. Checking. |
|
Hmm...I see the jar in the gem. |
|
Can someone post a terminal session showing the problem? I can't reproduce here. |
|
Someone beat me to it 👍 |
|
This only happens when I move to JRuby 1.7.11 it works fine if it is on 1.7.9 (not sure if it has anything to do with it) |
|
LoadError: no such file to load -- thread_safe/jruby_cache_backend |
|
I will yank the 0.3.0 gem until I can figure out why you folks are seeing
|
|
Ok, thanks. On Mon, Mar 17, 2014 at 10:57 PM, Charles Oliver Nutter <
Thanks! Blia Xiong |
|
I'm still not able to reproduce this: This was under 1.7.11, which @alexfalkowski said triggered the issue for him. Does this command fail for all of you? |
|
Can someone give me a listing of the installed gem's lib/thread_safe dir? I am assuming the jar's not there for some reason, but if it's there then something else is going on. |
|
Also, does 0.2.0 work ok with 1.7.11? I'm totally stumped here. |
|
it does. i had to uninstall 0.3.0. On Tue, Mar 18, 2014 at 11:37 AM, Charles Oliver Nutter <
Thanks! Blia Xiong |
|
The 0.3.0 installs and works fine for 1.7.9 (which I'm not sure why that is the case). Looking at the contents of the lib folder for thread_safe-0.3.0-java this is what I have ├── thread_safe |
|
Ok...I'm really confused. The gem looks fine, and the diff between 0.2.0 and 0.3.0 does not show anything that might cause this require to fail. At least one person reported that 0.3.0 does work properly with JRuby 1.7.9...what about the rest of you? What JRuby version are you using? I have yanked the gem even though it looked fine. I have a couple unlikely theories to test out. |
|
Those of you having trouble...I need your help. If you don't have the gem anymore you can download it manually here: https://rubygems.org/gems/thread_safe/versions/0.3.0-java
|
|
Installed the gem and can't seem to reproduce the error with the given On Wed, Mar 19, 2014 at 8:32 AM, Charles Oliver Nutter <
Thanks! Blia Xiong |
|
@bliaxiong Are you saying 0.3.0 gem works now for you? |
|
Yes. I was seeing the issues when running 'rails new my_app' with JRuby I downloaded and manually installed the gem. I ran your command without any Running gem list shows this: thread_safe (0.3.0 ruby java, 0.2.0 java). I On Wed, Mar 19, 2014 at 9:01 AM, Charles Oliver Nutter <
Thanks! Blia Xiong |
|
I don't see thread_safe 0.3.0 gem file in rubygems so not able to bundle. Fetching additional metadata from https://rubygems.org/.. but adding this works gem 'thread_safe', :github => 'headius/thread_safe' |
|
Although the gem is yanked, it's possible to download it from rubygems directly: http://rubygems.org/gems/thread_safe/versions/0.3.0 I've also tried to reproduce the issue, but rails new foobar seems to work fine: alexfalkowski (or whoever can reproduce the issue) could you provide steps to reproduce it from a clean gemset? |
|
I tried on rails 4.0.4 actually I was running 4.0.2 and I then upgraded to SENT FROM MY HTC Butterfly S
|
|
@ratnikov I think you've created new app but you didn't removed(uninstall) the gem so It would have picked from the old gems you had on your local drive. if you'll see in 'gem list' then remove version 0.3.0 and then do bundle, I'm sure you gonna get the error. |
|
Huh? If I uninstall it and try to run bundle install, it fails to find it (duh), but doesn't raise any weird errors: |
|
So I have tried it in JRuby 1.7.9. gem install atomic -v 1.1.7 gem install --local thread_safe-0.3.0.gem gem install rails -v 4.0.3 rails new foobar I made sure I created a new ruby-gemset. This is what the contents of the gem look like: /Users/alexfalkowski/.rvm/gems/jruby-1.7.9@test-thread_safe/gems/thread_safe-0.3.0 16 directories, 40 files |
|
I get the same issue with 1.7.11. Seems like there might be something up with the gem? |
|
I think there may be some mismatching gem version out there. A couple theories.
I am in transit for the next day or so, but I (or @thedarkone) will push a new 0.3.1 gem that has no changes and have you all retest. |
|
Cheers 👍 |
Can't help with this right now 😢 (don't have access to dev env for a few days). |
|
I have pushed a 0.3.1 gem that's identical to the old one, because I can't reproduce and can't figure out what would be causing issues for you all. If the new version doesn't work either, I need you to work with me to figure it out. Run your app/command with -Xdebug.loadService=true passed to JRuby (or in JRUBY_OPTS) and find relevant output when it looks for the jar it can't find. If it's still broken, open a new issue for 0.3.1. |
|
Just tried it and it seems to be working, thanks for the update :) |
@headius, please consider not yanking gems in the future for issues like this. When you yank a gem, it means that users who have the yanked version in their We're on MRI and haven't hit this bug with v0.3.0 (since it appears to be jruby-specific) so it was surprising to suddenly have bundles fail. FWIW, I think rubygems needs some other way to tag a specific version as "problematic" or "not recommended", and I'm going to go open an issue to suggest they add alternative to yanking for things like this. |
|
@myronmarston I’ve convinced @indirect and @hone that this is worth fixing in Bundler, so gems in the |
|
@sferik Thanks, that does sound like a better approach. Given that the gem was still downloadable from rubygems.org, I assumed it would be lower impact to yank than it actually was. @myronmarston At the point I decided to yank this, I assumed the gem was totally broken. Not yanking it would mean even more people ended up with a broken gem in their Gemfile.lock, which means more support hassles for me. The delay between yanking and pushing a new gem was unexpected and unfortunate, but I was really stuck between two not-so-great options. |
|
I came across this issue again, in 0.3.3. After some investigation, this is what I found. I use "bundle install --deployment" for vendorizing gems into vendor/bundle. Then, I check-in the vendor/bundle directory into git. When doing that, bundler untars the gem into that directory. The thread_safe gem has been packaged with a .gitignore file (the same one that is checked in, into code). That .gitignore file ignores "lib/thread_safe/jruby_cache_backend.jar". When checked into git, the .gitignore kicks in, and the jruby_cache_backend.jar is not checked in. Locally, it stays and so it works for some people. But, if you do a "git clean -fdx" or clone it somewhere else, the jar is not going to be around. If this is what was happening to the others too, it could explain why #39 talked about the gem not changing between 0.3 and 0.3.1. Looking at the yanked gem, it DOES have that jar file. So, it was not corrupted. I think the thread_safe.gemspec file needs a line like this in it, to make sure that the .gitignore is not packaged: |
|
That usage pattern for Bundler is completely unsupported, and any problems you encounter while using it are your own to solve, I'm afraid. (That said, I also recommend not including gitignore files inside packed gems. :) On Tue, May 6, 2014 at 8:14 AM, Aravind SV notifications@github.com
|
:) Agreed. Also, I meant to say, "bundle install --standalone --path vendor/bundle", instead of --deployment. [Off topic] In my case, I'm using embedded JRuby (jruby-complete.jar) inside a war. So, I need the gems available and not dependent on anything else. That's why the vendoring. |
|
Wow, @arvindsv thanks for digging into it! 👍 I'll make sure |
Bad release?
The text was updated successfully, but these errors were encountered: