Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

More semantic colors in bundle update #5506

Closed
brchristian opened this issue Mar 7, 2017 · 4 comments
Closed

More semantic colors in bundle update #5506

brchristian opened this issue Mar 7, 2017 · 4 comments

Comments

@brchristian
Copy link
Contributor

One thing I have noticed in recent versions of bundler is helpful colors in the command line. Overall I think this is great. However I noticed that the comparison of old gems to new ones is green even when the gem version is regressing. Here’s a screenshot:

screen shot 2017-03-07 at 11 18 46 am

Notice that all of these gems have gone backwards!

I would suggest a color like yellow/amber for all decrementing gems, as this will (I think appropriately) direct the user’s attention to these items and make sure that there are not any unintentional regressions.

Happy to submit a PR if there is interest in this.

@segiddins
Copy link
Member

I think this would be really cool!

@indirect
Copy link
Member

indirect commented Mar 8, 2017

👍

@colby-swandale
Copy link
Member

closing this, use the PR instead for any feedback.

@segiddins
Copy link
Member

We'll close the feature request when the PR is merged

bundlerbot added a commit that referenced this issue Mar 29, 2017
use yellow color when version appears to be moving backwards

This is very much intended as a work in progress (no tests!) and proof-of-concept .
Closes #5506.

In cases where the _dependencies_ change, it is not always possible to tell if they are going forwards or backwards -- for instance a change from `> 2.0` to `< 2.8` is neither obviously a forward or a backward change.

Hence the behavior here is to always default to the green color unless there are two specific version numbers and the new one is strictly less than the old one, in which case we use the yellow color.

I’d love any code review and any suggestions for the right place to add some tests for this. I think the tests should end up being quite simple -- we can check for `\e[32m` (green) versus `e[33m` (yellow) in the strings sent to the shell, and that’s easy enough -- but I’m simply not familiar enough with the test suite to know the appropriate place and syntax to do that. Suggestions welcome!
philipefarias added a commit to dleemoo/rc-images that referenced this issue Jun 12, 2017
Changes since last version used (1.14.6):

== 1.15.1 (2017-06-02)

Bugfixes:

  - `bundle lock --update GEM` will fail gracefully when the gem is not in the lockfile (rubygems/bundler#5693, @segiddins)
  - `bundle init --gemspec` will fail gracefully when the gemspec is invalid (@colby-swandale)
  - `bundle install --force` works when the gemfile contains git gems (rubygems/bundler#5678, @segiddins)
  - `bundle env` will print well-formed markdown when there are no settings (rubygems/bundler#5677, @segiddins)

== 1.15.0 (2017-05-19)

This space intentionally left blank.

== 1.15.0.pre.4 (2017-05-10)

Bugfixes:

  - avoid conflicts when `Gem.finish_resolve` is called after the bundle has been set up (@segiddins)
  - ensure that `Gem::Specification.find_by_name` always returns an object that can have `#to_spec` called on it (rubygems/bundler#5592, @jules2689)

== 1.15.0.pre.3 (2017-04-30)

Bugfixes:

  - avoid redundant blank lines in the readme generated by `bundle gem` (@koic)
  - ensure that `open-uri` is not loaded after `bundle exec` (@segiddins)
  - print a helpful error message when an activated default gem conflicts with
    a gem in the gemfile (@segiddins)
  - only shorten `ref` option for git gems when it is a SHA (rubygems/bundler#5620, @segiddins)

== 1.15.0.pre.2 (2017-04-23)

Bugfixes:

  - ensure pre-existing fit caches are updated from remote sources (rubygems/bundler#5423, @alextaylor000)
  - avoid duplicating specs in the lockfile after updating with the gem uninstalled (rubygems/bundler#5599, @segiddins)
  - ensure git gems have their extensions available at runtime (rubygems/bundler#5594, @jules2689, @segiddins)

== 1.15.0.pre.1 (2017-04-16)

Features:

  - print a notification when a newer version of bundler is available (rubygems/bundler#4683, @segiddins)
  - add man pages for all bundler commands (rubygems/bundler#4988, @feministy)
  - add the `bundle info` command (@fredrb, @colby-swandale)
  - all files created with `bundle gem` comply with the bundler style guide (@zachahn)
  - if installing a gem fails, print out the reason the gem needed to be installed (rubygems/bundler#5078, @segiddins)
  - allow setting `gem.push_key` to set the key used when running `rake release` (@DTrierweiler)
  - print gem versions that are regressing during `bundle update` in yellow (rubygems/bundler#5506, @brchristian)
  - avoid printing extraneous dependencies when the resolver encounters a conflict (@segiddins)
  - add the `bundle issue` command that prints instructions for reporting issues (rubygems/bundler#4871, @jonathanpike)
  - add `--source` and `--group` options to the `bundle inject` command (rubygems/bundler#5452, @Shekharrajak)
  - add the `bundle add` command to add a gem to the gemfile (@denniss)
  - add the `bundle pristine` command to re-install gems from cached `.gem` files (rubygems/bundler#4509, @denniss)
  - add a `--parseable` option for `bundle config` (@JuanitoFatas, @colby-swandale)

Performance:

  - speed up gemfile initialization by storing locked dependencies as a hash (@jules2689)
  - speed up gemfile initialization by making locked dependency comparison lazy, avoiding object allocation (@jules2689)
  - only validate git gems when they are downloaded, instead of every time `Bundler.setup` is run (@segiddins)
  - avoid regenerating the lockfile when nothing has changed (@segiddins)
  - avoid diffing large arrays when no sources in the gemfile have changed (@segiddins)
  - avoid evaluating full gemspecs when running with RubyGems 2.5+ (@segiddins)

Bugfixes:

  - fix cases where `bundle update` would print a resolver conflict instead of updating the selected gems (rubygems/bundler#5031, rubygems/bundler#5095, @segiddins)
  - print out a stack trace after an interrupt when running in debug mode (@segiddins)
  - print out when bundler starts fetching a gem from a remote server (@segiddins)
  - fix `bundle gem` failing when `git` is unavailable (rubygems/bundler#5458, @Shekharrajak, @colby-swandale)
  - suggest the appropriate command to unfreeze a bundle (rubygems/bundler#5009, @denniss)
  - ensure nested calls to `bundle exec` resolve default gems correctly (rubygems/bundler#5500, @segiddins)
  - ensure that a plugin failing to install doesn't uninstall other plugins (@kerrizor, @roseaboveit)
  - ensure `socket` is required before being referenced (rubygems/bundler#5533, @rafaelfranca)
  - allow running `bundle outdated` when gems aren't installed locally (rubygems/bundler#5553, @segiddins)
  - print a helpful error when `bundle exec`ing to a gem that isn't included in the bundle (rubygems/bundler#5487, @segiddins)
  - print an error message when a non-git gem is given a `branch` option (rubygems/bundler#5530, @colby-swandale)
  - allow interrupts to exit the process after gems have been installed (@segiddins)
  - print the underlying error when downloading gem metadata fails (rubygems/bundler#5579, @segiddins)
  - avoid deadlocking when installing with a lockfile that is missing dependencies (rubygems/bundler#5378, rubygems/bundler#5480, rubygems/bundler#5519, rubygems/bundler#5526, rubygems/bundler#5529, rubygems/bundler#5549, rubygems/bundler#5572, @segiddins)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants