`gem update` of multiple gems should identify those already up to date #544

MarkDBlackwell opened this Issue Apr 23, 2013 · 3 comments

3 participants


Some standard output information is lacking when multiple gems are updated by gem update. The already up to date gem names should be added.

Surely this is proper after supplying multiple gem-name arguments. It's probably desirable as well without gem-name arguments (this of course updates all local gems).

Clearly, the 'gem update` command doesn't otherwise try to remain 'silent on success' as many Unix commands do. So that idea doesn't properly justify this lack.

Also, having this information appear only in verbose mode would be insufficient (it would be no improvement) because normally people don't use verbose mode the first time they try a command. And one of this issue's main goals is to save users' time.

If only one gem is supplied in its argument list, 'gem update' then outputs some helpful information which enables the user to conclude that the single gem is up to date. For instance:

$ gem update rake
Updating installed gems
Nothing to update

Not so for multiple gems! As an example, let's suppose (unbeknown to the user) that gem 'rake' (already) is up to date. Then gem update bundler rails rake produces no informative message about gem rake.

The output produced, which is 'Gems updated: bundler, rails', does tell the user about those gems but says nothing about gem 'rake' except by omission. The up-to-date status of gem 'rake' is unconfirmed!

It is likely the user will assume something is wrong with their command. Just for example, they might suppose they misspelled the gem name; or, they might suppose the argument list is limited to only two gems. We know these possibilities aren't so but it would take the user time to investigate them.

To make sure, the user then might enter gem update rake. Of course this adds a frustrating delay which is totally unnecessary because already gem update bundler rails rake had checked the sources and found gem 'rake' was up to date. But it just didn't tell the user!

Also, this fix seemingly would be easy and involve no documentation change.

$ gem --version
$ ruby --version
ruby 1.9.3p392 (2013-02-22 revision 39386) [i686-linux]
$ cat /proc/version
Linux version 2.6.32-5-686 (Debian 2.6.32-48squeeze1) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Feb 25 01:04:36 UTC 2013
RubyGems member

Why do you assume some error happened if "rake" is not explicitly listed as up-to-date?

For other commands an error is shown if some action could not be completed.


Why do you assume some error happened if "rake" is not explicitly listed as up-to-date?

I (and many users) don't assume that some error happened. We don't know what happened. The precise behavior (in this regard) of e.g. gem update rails rake is not easy for many users to remember.

Daily, users enter some subset of their usual commands, which silently ignore some further arguments and give no error message.

Currently, for example, gem list rails rake silently ignores its final 'rake' argument.

Since no particular pattern is universal in the users' experience (in this regard), for each command they must try to remember the peculiarities of its hidden behavior. That is true unless the command's response indeed explicates this aspect of its behavior—by including a message such as, 'gem rake is up to date'.

The problem is exacerbated when multiplied by the great number of commands the users enter frequently.

For other commands an error is shown if some action could not be completed.

The user isn't told (and they cannot infer, as explained above) that any action could not be completed. If the software remains silent about it, the issue is whether some requested action was even undertaken (or not). This is a UX issue.

RubyGems member

I have no evidence for "many users" as only you have spoken up about it. Now you have a clear understanding of how the messaging works.

Anyhow, I will leave this open as a feature request but I have no intention of implementing it as it does not appear to be generally confusing. A pull request for this issue would be appreciated.

@drbrain drbrain closed this in 1b92cc6 Feb 5, 2014
@drbrain drbrain added a commit that referenced this issue Feb 5, 2014
@drbrain drbrain Add #544, #777 to History 7d1958c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment