Bugs item #29176, was opened at 2011-05-06 13:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126
Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Chaffee (alexch) Assigned to: Ryan Davis (zenspider) Summary: Scary warnings are scaring helpless developers who can't do a thing about it Initial Comment: Suddenly anyone using "gem" is seeing many repetitions of lines like this: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /Users/chaffee/.rvm/gems/ruby-1.9.2-p0/specifications/thin-1.2.7.gemspec:10. Many of my students are completely freaking out since something that's supposed to just work -- e.g. "gem install rails" or "gem list"-- is now spewing a huge amount of scary noise about things which are currently working just fine, and which they have no ability to affect. Even developers with the acumen to be able to read, understand, and react to these messages are wasting time googling, often fruitlessly, since even if they find Ryan's blog post, and run "gem pristine --all --no-extensions", it doesn't make all the warnings disappear. Here's my suggested fix, in three independent parts. 1. Stop repeating the same message again and again; instead set a global flag (already_scared_user?) and STFU if it happens for a different gem 2. Put the advice about running "gem pristine --all --no-extensions" in the error message instead of forcing people to google to find a workaround 3. Before the warning, try to rewrite the offending gemfile yourself, as if the user had run "gem pristine". If the rewrite fails, only then scare the user. And please remember that the "gem" command is the user interface to the entire world of Ruby development, for people of all experience levels. You have a responsibility not to scare off our friends, new and old. ---------------------------------------------------------------------- >Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-24 17:05 Message: We are now getting duplicate pull requests in addition to Alex's (https://github.com/rubygems/rubygems/pull/66#issuecomment-1232323). May we please have the active maintainers weigh in on whether or not Alex's pull request can or cannot be merged? We can probably arrange to discuss on IRC if that is necessary... ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-22 16:38 Message: Is there any reason not to merge Alex's patch? https://github.com/rubygems/rubygems/pull/59 He stepped up and wrote some code to make the situation better, and had it code-reviewed by Evan. Can we at least merge that or give feedback? ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-22 14:06 Message: I suspect this ticket not going to be resolved and is falling on deaf ears the ratio of "suck it up" responses to the "this sucks, please help" comments. If this is thie case, please just close this ticket with a resolution of whatever rubyforge's equivalent of "won't fix" with relevant links to workarounds. ---------------------------------------------------------------------- Comment By: Beoran Aegul (beoran) Date: 2011-05-22 01:10 Message: +1 for solution 1. Running gem pristine broke my rubygems, so I think it's a non-solution. I understand the need to clean up rubygems, but trying to force the whole ruby world to upgrade their gems specs so suddenly is not a good idea, IMHO. Not to mention many useful gems out there that are not maintained actively anymore. Kind Regards, B. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-18 13:45 Message: Ping. My patch https://github.com/rubygems/rubygems/pull/59 doesn't change the inner workings at all, just improves the way deprecations are reported. Given that the idea is to get people to pay attention to them, it seems like people are more likely to pay attention to an organized list than a disorganized flood (especially since the list removes duplicates). Evan has code reviewed the patch and I implemented all his suggestions. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 14:58 Message: Ryan, I think I did these steps before 1.8.2, I haven't tried it yet. Also since all my gems are fixed now, can't test again :-) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-12 14:19 Message: Luis, unless I'm not understanding the rvm gem setup correctly, there is no need to do the `rvm use` line anymore. pristine had a bug with multiple repos that was fixed in 1.8.2. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 09:44 Message: Thanks, Luis, for that tip. I guess that means to upgrade rubygems the user is obligated to: rvmsudo bash gem pristine --all rvm use 1.9.2-p180@global gem pristine --all Where this is documented other than this ticket, I have no idea. If I hadn't spent hours trying to remedy this, I would've just reverted to gem 1.6.0 and called it a day. If the intent of these warnings is to get people to upgrade, I have a feeling the opposite thing will occur. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-12 08:22 Message: @Scott Tadman: gem pristine with "--no-extensions" will not fix gems that have extensions, that includes rcov, json, perftools. For that, you need "gem pristine" alone. As for rake, it is placed in the global namespace of RVM, so you need to switch to that namespace and correct it: rvm use 1.9.2-p180@global gem pristine rake Then switch to your normal gemset. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-12 08:11 Message: Further investigation reveals that Jeweler's generated .gemspec file is affected by the version of rubygems installed, and that if building against a newer rubygems it will not put in the default_executable= call, so at least that much is fixed. However, the catch-22 here is that you need to build using a newer version of rubygems, which because of all the crazy warnings you get, I'm sure a lot of developers would avoid, instead reverting to an earlier, safer version. I have run gem pristine --all --no-extensions over six times on an OS X rvm-based Ruby 1.9.2 set of system gems and I'm still getting warnings. The first pass removed most, the second some, and the rest virtually none. I'm not sure why this needs to be run more than once in the first place, nor why this is the responsibility of the user. Now anything that even touches rubygems ends up getting lit up with warnings, the final few of which appear to be the most stubborn: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180@global/specifications/rake-0.8.7.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/json-1.5.1.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/perftools.rb-0.5.6.gemspec:10. NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /opt/local/rvm/gems/ruby-1.9.2-p180/specifications/rcov-0.9.9.gemspec:11. (in /Users/tadman/git/pigeon) It is worrying that the pristine operation not only produces ~500KB of warnings when processing its various things which buries any actual errors in the process. Maybe there's a reason why these gems can't be pristined properly, but it gets lost in the hurricane of warnings. ---------------------------------------------------------------------- Comment By: Mike Bethany (mikbe) Date: 2011-05-12 00:36 Message: The deprecation warnings made it virtually impossible to work. Every time autotest ran I would have a screen full of gobbledygook I had to sort through, very annoying. I wrote Chicken Little to disable the deprecation warnings just for the two major offenders. You can install the gem with: `gem install chicken_little` then run it `chicken_little install` You can also just go in and edit the RubyGems specification.rb file yourself and comment out those lines. Source: https://github.com/mikbe/chicken_little RubyGems: https://rubygems.org/gems/chicken_little P.S. RubyGems 1.8.2 seems to be broken in Ubuntu 10.10. Funny enough in the specification.rb file at line 277. Though it seems to be OK in OS X 10.6.7. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-11 16:25 Message: I've gone ahead and made a patch. My fork of rubygems still prints out warnings, but after the first warning, it buffers up all remaining warnings and then emits them at_exit in a somewhat nicer report format, like this: Some of your installed gems called deprecated methods. See http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html for background. Use 'gem pristine --all' to fix or 'rubygems update --system 1.7.2' to downgrade. TestDeprecate::Thing#foo is deprecated; use bar instead. It will be removed on or after 2099-03-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:174 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:175 called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:177 TestDeprecate::Thing#goo is deprecated; use bar instead. It will be removed on or after 2099-04-01. called from /Users/chaffee/dev/rubygems/test/rubygems/test_deprecate.rb:176 I also pulled in the "--no-warnings" patch, but set the default back to "show all warnings" (i.e. skip=false). https://github.com/alexch/rubygems/commit/5572c2c1bb88e2e1b55b8d62 3fe4ef58a954c2a1 ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-11 11:06 Message: Part of this problem is that Jeweler, a gem used by many authors to build their gems, inserts the default_executable= line in all the .gemspec files it produces. This is something done without the knowledge of the authors, and as one, I'm not even sure how to turn it off. I'll have to do more research. In the mean-time I need to live with the guilt and shame of causing warnings for everyone using anything I've made. I do want to keep up to date. I use Ruby 1.9.2 and the latest everything for new projects, but there are many legacy applications I'm involved with that for reasons of budget, dependency hell, or otherwise, are constrained to specific older versions. What I'm asking is why methods can't be deprecated by rendering them non-functional instead of causing things to explode by calling methods that no longer exist. It is common practice amongst UNIX shell utilities to have non-functional arguments for this very reason. I'm not saying to support the API, but at least make it mostly compatible with the newest spec even if it may not perform exactly as intended. For instance, most browsers don't support the <blink> tag, but they also don't refuse to render the page because of a lack of support. Once again, these are not my "decrepit needs", but rather the fact that there are hundreds if not thousands of gems out there with this mostly useless call to default_executable= as inserted by Jeweler and others that could be harmlessly ignored. I will post another ticket relating to the warnings later if I can replicate it. I have mostly fixed the issue using the pristine option which should be advertised more clearly or, better yet, done automatically when gem is updated to the newest release. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-11 02:02 Message: Scott, Please file a ticket with details and, if possible, reproduction steps showing that rolling back to 1.7.2 still has deprecation warnings that were added to 1.8.0. If it isn't too much to ask, please file a ticket with details and, if possible, reproduction steps showing "literally, 4000+ lines of warnings when running ordinary rake tasks" after running `gem pristine --all --no-extensions`. Do note that I suspect there is a bug in `gem pristine` in scenarios like using rvm w/ multiple gem directories... I don't have a repro for that yet. Finally, the majority of these deprecations are created _by_ rubygems in gemspecs and are fixable _by_ rubygems (pristine bugs notwithstanding)... Those warnings that are left afterwards represent real usage of methods that ARE going away. You state that you're intentionally running old gems on your apps but you insist on updating rubygems & bundler... You're going to update to a version that doesn't have the implementation one of your decrepit needs. What is your plan for that? Do you really think it reasonable that we should keep around API supporting everything all the way back to 2004? I'm sorry, but that just doesn't seem sane to me. We have to move on, even if you won't. ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 21:37 Message: This issue is driving me berserk. I've pristined, I've rolled back to 1.7.2 like the Germans retreating from Russia and still I'm getting nagged and hassled. When something like default_executable is specified in default gemspec files that Jeweler produces and other templates that many have used to build out their gemspecs, it does seem like a bit of a nuisance. Maybe it's better to rescind support for it and turn it into a method that does nothing simply for compatibility reasons. Document the method as deprecated and non-functional for the curious. Lobby to get it removed from examples and places like Jeweler. I have applications with dozens of deliberately old versions of gems because the associated applications aren't up to date and upgrading causes problems. The one thing I do want to keep up to date is support utilities like gem and bundler, though, and getting, literally, 4000+ lines of warnings when running ordinary rake tasks is not helping. Even if I nagged and hassled every single gem builder, and seriously, I have nagged many about Ruby 1.9 issues, this still wouldn't matter because I simply have older versions of gems installed that cannot be patched without altering the space-time continuum. This is basically condemning me to using an antiquated version of gem so long as I have even one squeaky wheel in the whole system, as a single out of date gem will produce warnings for every gem related operation. When installing a new gem, if strictly necessary, it could say that the .gemspec is out of date and should be updated while hinting at the obscure pristine command as to how that might remedy it. I have wildly different versions of gem installed on my systems, but it's as if every time I go to update to the latest I get slapped in the face with something like this. I honestly wonder how other people have fared. After a lot of fussing about, experimenting with different approaches and attempting to be as unobtrusive as possible, I have come up with a patch that enables Deprecate.skip by default and also allows the setting to be toggled on or off as desired using the --warnings or --no-warnings options for install. After inspecting the implementation of this, which appears to have erupted into the root namespace as the module Deprecate, and without any sort of unit test, I have inverted the default because warnings are generated before command options are processed and there does not appear to be any other way. Patch: https://gist.github.com/965921 ---------------------------------------------------------------------- Comment By: Stephen Bannasch (stepheneb) Date: 2011-05-10 20:13 Message: For now I'm using this solution: gem update --system 1.7.2 Thanks Luis -- I didn't remember how easy it was to downgrade RubyGems. After running: gem pristine --all --no-extensions -- running a single spec test In my rails 2.3.11 project with RubyGems 1.8.1 generates 317 lines of warnings before I see the 10 lines of results: https://gist.github.com/965850 It's certainly annoying enough to get me to plan to fix my gem (jnlp) but my one gem is just a tiny bit of the noise in general. ---------------------------------------------------------------------- Comment By: Jordan Sissel (jordansissel) Date: 2011-05-10 18:36 Message: FWIW, I support deprecations, but these warning messages are going to users, not developers. And that sucks. For example, all my ruby nagios alerts are filled, now, with pointless warnings about libraries my code is *not* using. So many warnings, in fact, that the test code's output is lost. This warning should pop up when developers run 'gem build foo.gemspec' and no other time. Why? Consider a user who has code that relies on rake '0.8.0' explicitly. You can't actually fix 'rake 0.8.0' on rubygems.org because you can't overwrite an existing release (for good reason). So now, for eternity, this user is stuck with warning messages. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-10 10:55 Message: Chad - A two-line warning per gem would still be super noisy. One compromise would be to queue up a list of offending gems per warning and then emit them all on_exit in a single line. As for patches, as I said before, I'd be happy to spend my time working on that, but not until I get the goahead from a member of the core team (especially considering that first comment). ---------------------------------------------------------------------- Comment By: Scott Tadman (tadman) Date: 2011-05-10 09:26 Message: I just "upgraded" gem and now I'm greeted with over a thousand lines of warnings, nearly one for every gem I have installed on my system. It doesn't just warn for gems I use, but any gems I might happen to have that are out of date. The message itself is meaningless as there's really nothing I can do about it, and further, it doesn't seem like ignoring that directive instead of complaining about it would have much of an effect on the end user. Since when is it the responsibility of gem users to hassle gem builders into compliance? Why can't the gem build operation give the builder a hard time instead? Why can't rubygems.org reject the gem out of protest? As a note, I'm also getting a kabillion identical warnings apparently from rubygems itself: Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. Gem::SourceIndex#add_spec called from /opt/local/rvm/rubies/ree-1.8.7-2011.03/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:127. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2011-05-08 11:43 Message: I agree, it would be nice if the deprecation warning were once per gem (NOT once for all gems as Alex suggested; that would defeat the purpose of getting people to complain to gem authors to fix their specs) However, I don't see any patches or even failing tests attached to this ticket yet... ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-08 09:40 Message: Ryan, I'm not too sure if you read the entirety of my message. Just in case, I'll summarize again: 1. I agree that having warnings telling developers to update their APIs is good. I believe I said that. (Feel free to check) 2. The issue in this report is not about whether the warnings should exist or not, because everybody here agrees they should. The issue is how often they need to be printed. Given that I am suggesting the same fix as Alex, I don't see how this falls out of the scope of the ticket. 3. My feedback was not (entirely) a "me too". I am simply trying to provide extra information regarding the breadth of this issue that others might not be aware of; specifically that `gem pristine --all` is not a complete solution to this issue, at least it does not guarantee the hiding of all warning *spam* (remember, not arguing about first-time warnings, but complete page-spam). As far as I know, that problem was not yet discussed. I'm of the opinion that all relevant information should be provided with a bug report. There's no need to jump down users throats for providing extra information, so please try to use your indoor voice. 3. I don't see why modifying the warnings to show once (per method) needs to be controversial. It seems like quite a simple and reasonable change, at least to me. Is it not reasonable to you? Why not? Finally, as far as I know, open source relies on feedback from the community; certainly a tool that is widely used and part of Ruby's standard library deserves feedback from all of the community. Telling users that they are not allowed to voice their opinion on an open ticket simply does not compute. I'm therefore politely declining your invitation to "get off this ticket". Though, I suppose this should have prefaced the response with this note instead. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 01:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:54 Message: Justin, As described at http://blog.zenspider.com/2011/05/rubygems-18-is-coming.html and elsewhere, rake is one of those unfortunate gems that explicitly uses the deprecated API in their gemspec. Please file a bug on the rake bug tracker. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-07 23:53 Message: Loren, Get off this ticket. Everything you just described falls outside of the scope of this ticket. Specifically: "helpless developers". The point of having deprecations at all is to get those "hundreds" of libraries that use deprecated API to update their code. If you want to "me too", then yippie... but your hyperbole isn't a "me too" it is a completely separate issue (and one I will more readily reject). ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-07 23:19 Message: I did a fresh install of 1.9.2 with rvm, then upgraded Ruby Gems. The only gem installed was "rake", and after running "gem pristine --all", "gem pristine --all --no-extensions", and "gem pristine rake", I still get the following error: NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01. Gem::Specification#default_executable= called from /home/justin/.rvm/gems/ruby-1.9.2-p180@global/specifications/rake-0.8.7.gemspec:10. ---------------------------------------------------------------------- Comment By: Loren Segal (lsegal) Date: 2011-05-07 22:40 Message: I have to agree with the severity of this issue. The problem is unfortunately not just limited to the `gem` binary. Any library making use of deprecated APIs will also get these warnings ad-infintum, so gem pristinie --all doesn't solve this issue, only small one part of it. For example, any gem that makes use of SourceIndex will see these deprecation warnings on each usage. There are currently hundreds of libraries that make use of this class, as per my latest search on codesearch: http://codesearch.google.com/codesearch?q=SourceIndex+lang:ruby and http://codesearch.google.com/codesearch?q=Gem.source_index+lang%3Aruby You might get lucky and just see a few of these warnings, but if the method is called within a loop, RubyGems will not be forgiving, and spam you many, many, times (see http://codesearch.google.com/codesearch/p?hl=en#L18QHnAzSFA/bin/minigem&q=Gem.source_index%20lang:ruby&sa=N&cd=46&ct=rc for just one random example). In some cases, this output may even render the lib/tool completely unusable, especially if it relies heavily on console output. Because of that possibility, an otherwise innocuous (and transitional) warning can become a "severe" compatibility bug. Just like Alex, I'm all for warnings, but I foresee a lot of developers scrambling to provide fixes for their users in the coming months, especially in the cases where their tools start scrolling pages of warnings just because of one method call. I'm not sure devs or users will be too happy about this. Fortunately the fix is simple, as Alex pointed pointed out. I think it would be sensible to add the suggested "already_scared_user?" flag; it can probably be done on a per method name granularity. Given that all of the deprecations are wrapped inside a Deprecation module AFAIK(?), this should be pretty simple to add. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 15:04 Message: Which gem was not solved by gem pristine --all? please provide complete output, we can't help without the output. As for drowning on this issue: revert back to 1.7.2 There is no easy way to solve existing gem specifications without doing gem pristine --all And we can't help solve the others without people telling us which ones didn't get fixed for us to look at *why*. So, I know were are you coming from, heck, I work on Windows, what more weird scenario for failures could be than that? And even so, gem pristine --all solved all the issues. Help us help you. ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 14:41 Message: Luis - thanks, "gem pristine -all" has fixed most -- but still not quite all -- of the messages. Warnings are indeed good, but only until they become noise. That is extra bad since it can drown out other important information, especially for less experienced people who are mystified by everything coming down on the console. One reason I'm concerned about this is that tonight in two different cities we're doing a Railsbridge Ruby For Women Workshop Install Fest, and most of the students won't understand what's going on, and the volunteers may not either. This will add chaos to an already chaotic and frustrating session. Not your problem, I know, but I wanted you to know where I'm coming from. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-05-06 13:38 Message: gem pristine --all --no-extensions will fix the gems that do not have extensions You need to do gem pristine -all, but that will not accept parameters for each gem. In my case I didn't require additional parameters to each gem so a simple gem pristine --all solved all the warnings. Warnings are good, and as always, you can rollback to previous versions if you find it doesn't work for you: gem update --system 1.7.2 ---------------------------------------------------------------------- Comment By: Alex Chaffee (alexch) Date: 2011-05-06 13:27 Message: I wasn't trying to be inflammatory. This is a real problem, wasting the real time of real people across the world. And I'd be happy to submit a patch but somehow it doesn't seem likely you'd accept it. ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2011-05-06 13:22 Message: Really? Don't you have anything better to do than to post inflammatory shit to this tracker? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
