No, it is not. I’ll try to explain why it happens, why a fix is difficult, and what we’re doing to address it in future versions of Atom.
Updates are cached to improve performance the first time after updates are checked (which generally happens as soon as you open Atom). This is the only time that updates are automatically checked for without interacting with Atom in some other way (ie, going to the Updates panel).
The cache is cleared either when it reaches the cache timeout (10 minutes), or when packages are upgraded.
Now, the problem is that when you upgrade packages from within Atom, it emits events when packages finish updating. The cache gets sent those events and clears the cache. However, the
apm CLI does not have any way of sending those events to Atom. Basically, the settings-view shells out to
apm, and then interprets the results
apm sends back to emit the correct events. When you run
apm directly, the event sending doesn’t happen. Which means settings-view still thinks that you haven’t upgraded the packages, because it doesn’t know any better.
This is exacerbated by the cache, because when you think “wow, this is a bug” and try reopening the Updates panel, it hits the cache (since it’s under 10 minutes and no events have been received) and returns the same list.
So that’s pretty much why it’s difficult to fix: it’s hard to get a command-line tool to communicate to Atom. In future versions of Atom, explicitly clicking the “Check for Updates” button will clear the cache, returning the correct results.