Bugs item #29176, was opened at 2011-05-06 15: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: Stephen Bannasch (stepheneb) Date: 2011-05-10 22: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 20: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 12: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 11: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 13: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 11: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 03:56 Message: No worries. ---------------------------------------------------------------------- Comment By: Justin Collins (presidentbeef) Date: 2011-05-08 01:57 Message: Sorry, my mistake. I didn't notice that gem was called out specifically. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-05-08 01: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-08 01: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-08 01: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-08 00: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 17: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 16: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 15: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 15: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 15: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
