Better gem outdated list #4841
Better gem outdated list #4841
Conversation
ryanfox1985
force-pushed
the
master
branch
7 times, most recently
from
365c222
to
580dff2
Compare
|
Thanks for sending us a PR! The current output lists every gem alphabetically so that you can find a specific gem easily. If we separated each group, that would become impossible unless you already know beforehand exactly which group the gem is in. This could work as either an option (maybe |
|
Hello @indirect, thanks for the feedback! I think both of your proposals will duplicate and get dirty the code. In my case I have my Gemfile disordered and I check some repos and anybody is respecting the alphabetically in their Gemfile. I don't understand: What advantage do you have with the outdated list alphabetically ordered? In my case my application doesn't have 100% of coverage. My updating process is checks the gems outdated and if the environment is development or test I try upgrade executing the test. If the environment is production I do more safe trying some parts of the application or adding more test. With this PR I can check my outdated list by groups quickly and it saves space in the rows. Regards. |
|
Sorry, rebasing the last changes from master I closed by error the pull request. XD |
|
I see that this change makes Bundler better for you, but not everyone agrees. It is not okay to force everyone to this new output, so this change is only okay as an option to outdated or as a separate command. If you do not want to make this an option, I am sorry but we cannot accept it. I think this would be useful if it worked like |
|
Hello @indirect, I understand, I restored the outdated command and I added a option to outdated: But I have a problem with the option, I tried to add an method_option here: Also I will restore the test and I will create a new one with Regards. |
ryanfox1985
force-pushed
the
master
branch
4 times, most recently
from
cbde436
to
79d9856
Compare
|
Hello, I already solved with aliases. Regards. |
ryanfox1985
force-pushed
the
master
branch
5 times, most recently
from
9446de1
to
7aef259
Compare
|
Hello @indirect, I restored the outdated behavior
In both options the gems are ordered alphabetically inside the group. Regards. |
|
Hello @chrismo, I don't understand where is the conflict. Regards. |
ryanfox1985
force-pushed
the
master
branch
7 times, most recently
from
36e28f5
to
dd18010
Compare
Restore default outdated. Added command in cli: - bundle outdated --groups Added --group option. Groups with alphabetical order. Added test. Reverted.
|
looking it over |
|
looks good to me 👍 |
|
shoot - in pushing #5056 which re-includes this commit, it lost track of the prior CI build which already passed. It's building again, but ... it's not necessary. anyway, by morning should hopefully be all consistent. |
|
@homu delegate=chrismo |
|
✌️ @chrismo can now approve this pull request |
|
@homu r+ |
|
📌 Commit 3725a23 has been approved by |
|
⚡ Test exempted - status |
Better gem outdated list Hi, the current version of bundler is listing all gems with the group, I improve these list grouping the gems by group and not repeat the group every line. Current: ``` Outdated gems included in the bundle: * aasm (newest 4.11.0, installed 3.4.0, requested = 3.4.0) in group "default" * activerecord-import (newest 0.15.0, installed 0.13.0) in group "default" * annotate (newest 2.7.1, installed 2.7.0) in group "development" * authority (newest 3.2.0, installed 3.0.0, requested ~> 3.0.0) in group "default" * awesome_print (newest 1.7.0, installed 1.2.0, requested ~> 1.2.0) in groups "development, test" * aws-sdk (newest 2.5.1, installed 1.60.2, requested ~> 1.60.2) in group "default" * bootstrap-sass (newest 3.3.7, installed 3.3.5.1, requested ~> 3.3.5.1) in group "default" * capybara (newest 2.7.1, installed 2.5.0, requested ~> 2.4) in group "test" * capybara-email (newest 2.5.0, installed 2.4.0) in group "test" * codeclimate-test-reporter (newest 0.6.0, installed 0.4.7) in group "test" * coffee-rails (newest 4.2.1, installed 4.0.1, requested ~> 4.0.0) in group "default" * countries (newest 1.2.5, installed 0.9.3, requested ~> 0.9.3) in group "default" * country_select (newest 2.5.2, installed 2.1.1) in group "default" * dalli (newest 2.7.6, installed 2.7.4) in group "default" ``` Better group: ``` $ bundle outdated ===== Group default ===== * addressable (newest 2.4.0, installed 2.3.8) * puma (newest 3.6.0, installed 2.10.2, requested ~> 2.10.2) * rails-assets-Sortable (newest 1.4.2, installed 0.7.1, requested ~> 0.7.1) * rails-assets-jquery-file-upload (newest 9.12.5, installed 9.7.0, requested = 9.7.0) * rails-assets-jquery-ui (newest 1.12.0, installed 1.11.0, requested = 1.11.0) * rails-assets-superagent (newest 2.1.0, installed 0.21.0, requested ~> 0.21.0) * rollbar (newest 2.12.0, installed 2.7.1, requested ~> 2.0) * sidekiq-pro (newest 3.3.2, installed 3.3.1) ===== Group development ===== * brakeman (newest 3.3.3, installed 3.1.0) ===== Group development, test ===== * pry (newest 0.10.4, installed 0.10.3) * pry-doc (newest 0.9.0, installed 0.8.0) * rspec (newest 3.5.0, installed 3.3.0, requested ~> 3.0) * rspec-support (newest 3.5.0, installed 3.3.0) * rubocop-rspec (newest 1.4.0, installed 1.3.1) ===== Without group ===== * babel-source (newest 5.8.35, installed 5.8.34) * execjs (newest 2.7.0, installed 2.6.0) * hashie (newest 3.4.4, installed 3.3.1) * ice_nine (newest 0.11.2, installed 0.11.1) * mini_portile2 (newest 2.1.0, installed 2.0.0) * minitest (newest 5.9.0, installed 5.8.4) * multi_json (newest 1.12.1, installed 1.11.2) * multipart-post (newest 2.0.0, installed 1.2.0) * rails-assets-blueimp-canvas-to-blob (newest 3.3.0, installed 2.1.1) * rails-assets-blueimp-load-image (newest 2.6.1, installed 1.13.0) * rails-assets-blueimp-tmpl (newest 3.4.0, installed 2.5.4) * rails-assets-jquery (newest 3.1.0, installed 2.1.4) * rake (newest 11.2.2, installed 10.5.0) * rdoc (newest 4.2.2, installed 4.2.0) ``` Regards
Conservative updates on outdated Add conservative resolving behavior to outdated command. - [x] convert existing flags to --filter-* - [x] deal with strict flag - [x] make a 2.0 issue to consider making strict flags more consistent - [x] fix #5065 (outdated filter options don't work with `--strict') - [x] fix #5076 (outdated shouldn't say "Bundle up to date!" if results are just filtered out.) - [ ] document breaking change reasons? (_commit comment has something at least now_) - [x] what about `bundle show --outdated`? (_it's a much simpler version ... prolly just going to leave it alone for now?_) The flags as passed to the GemVersionPromoter _change_ resolution. <=1.13.2 of bundle outdated, those flags merely filter the output, with no influence on resolution. If the lockfile is set to foo 1.0.0, and all of the following exist: 1.0.1, 1.1.0, 2.0.0, then <=1.13.2 bundle outdated currently will show: `foo (newest 2.0.0, installed 1.0.0)` <=1.13.2 `bundle outdated --minor` simply filters away that line and won't show it. With these changes, `bundle outdated --minor` would be fed to the GemVersionPromoter and actually only resolve `foo` up to `1.1.0`. This gist shows how it currently works, filtering the output: https://gist.github.com/chrismo/0bc6cfa00f539787101a9a2c900616d3 It's unfortunate timing. They were only added in 1.12 ... I'm biased, but feel like the affect the flags have on resolution is of greater value, and would be better to keep in sync with how they work fed to the `bundle update` command as of 1.13, and we could add new --filter-patch flags to replace what they do currently. IIRC, there was some confusion at the time that Andre perhaps even thought these flags as of 1.12 would be affecting what the newest would resolve to, instead of just filtering the output, so - _if_ I'm remembering correctly, that's also influencing my opinion. But, I can be swayed by the breaking behavior argument. from @indirect in [this comment](#4841 (comment)): "IMO, this is what we were trying to do in 1.12, and failed to do because resolving is complicated. :/ I would be okay with this change on the grounds that the previous flags were documented so it sounded like they cause the new resolver aware behavior. 👍"
Conservative updates on outdated Add conservative resolving behavior to outdated command. - [x] convert existing flags to --filter-* - [x] deal with strict flag - [x] make a 2.0 issue to consider making strict flags more consistent - [x] fix #5065 (outdated filter options don't work with `--strict') - [x] fix #5076 (outdated shouldn't say "Bundle up to date!" if results are just filtered out.) - [ ] document breaking change reasons? (_commit comment has something at least now_) - [x] what about `bundle show --outdated`? (_it's a much simpler version ... prolly just going to leave it alone for now?_) The flags as passed to the GemVersionPromoter _change_ resolution. <=1.13.2 of bundle outdated, those flags merely filter the output, with no influence on resolution. If the lockfile is set to foo 1.0.0, and all of the following exist: 1.0.1, 1.1.0, 2.0.0, then <=1.13.2 bundle outdated currently will show: `foo (newest 2.0.0, installed 1.0.0)` <=1.13.2 `bundle outdated --minor` simply filters away that line and won't show it. With these changes, `bundle outdated --minor` would be fed to the GemVersionPromoter and actually only resolve `foo` up to `1.1.0`. This gist shows how it currently works, filtering the output: https://gist.github.com/chrismo/0bc6cfa00f539787101a9a2c900616d3 It's unfortunate timing. They were only added in 1.12 ... I'm biased, but feel like the affect the flags have on resolution is of greater value, and would be better to keep in sync with how they work fed to the `bundle update` command as of 1.13, and we could add new --filter-patch flags to replace what they do currently. IIRC, there was some confusion at the time that Andre perhaps even thought these flags as of 1.12 would be affecting what the newest would resolve to, instead of just filtering the output, so - _if_ I'm remembering correctly, that's also influencing my opinion. But, I can be swayed by the breaking behavior argument. from @indirect in [this comment](#4841 (comment)): "IMO, this is what we were trying to do in 1.12, and failed to do because resolving is complicated. :/ I would be okay with this change on the grounds that the previous flags were documented so it sounded like they cause the new resolver aware behavior. 👍"
Hi,
the current version of bundler is listing all gems with the group, I improve these list grouping the gems by group and not repeat the group every line.
Current:
Better group:
Regards