bundle outdated --strict

[davidblondeau]

I have a project with several ~> or exact version requirements because more recent versions are not compatible (rack, mysql2, tzinfo...) but still maintained on a stable branch.
I want to know if a maintenance/security fix version was released but bundle outdated does not enforce dependency requirements by default so its results are not actionable / noisy.

The --strict option only reports newer versions that match dependency requirements.

I am not sure how the command is used by others but it might even be that this should be the default behavior.

[indirect]

I think it makes more sense to explain this as "Only list newer versions allowed by your Gemfile requirements".

[davidblondeau]

I was struggling with how to explain it succinctly. I like your wording. Should I make the change or will you do it when you merge the patch in?

Thanks for accepting the patch.

[indirect]

This seems useful. Thanks for the patch!

[indirect]

Great!

[fschwahn]

This addition is amazing, however the output is still noisy / not actionable in the following case:
You have a gem with fixed dependencies (e.g. gem 'rails', '3.2.15' with dependencies activerecord (= 3.2.15), ...). Now, when I run bundle outdated --strict, rails does not appear anymore in the list (as expected, even though there are newer versions), but activerecord still appears, even though there is no way I can update it.
Same is true if one of the gems in the Gemfile has a ~>-dependency, which is not listed explicitly in the Gemfile.

I can't estimate how difficult it would be to implement the strict command like this, but it would make the output even more useful.

[indirect]

Yes, and it's basically impossible. We might be able to switch to a nested list, showing which gems are child dependencies of other gems. But it's not possible to magically know which strict deps "don't count".

[fschwahn]

Too bad, that would've been amazing. Thanks for taking the time to answer!

[davidblondeau]

I am revisiting this and would like to achieve something similar to @fschwahn's request.
The behavior I envisioned for "outdated --strict" when I implemented it was to get the same behavior than performing a dry run of "bundle update".

After looking at it more, I think I can actually achieve this fairly easily by harnessing the great job already done by the resolver and comparing current_specs with resolved_specs
where
current_specs = Bundler.load.specs
resolved_specs = Bundler.definition(:gems => gems, :sources => sources).tap(&:resolve_remotely!).specs

@indirect: Do you think it is ok to make that change?

[indirect]

Yeah, I think so. Sounds good. :)

On Thu, Jan 23, 2014 at 11:21 AM, David Blondeau [email protected]
wrote:

I am revisiting this and would like to achieve something similar to @fschwahn's request.
The behavior I envisioned for "outdated --strict" when I implemented it was to get the same behavior than performing a dry run of "bundle update".
After looking at it more, I think I can actually achieve this fairly easily by harnessing the great job already done by the resolver and comparing current_specs with resolved_specs
where
current_specs = Bundler.load.specs
resolved_specs = Bundler.definition(:gems => gems, :sources => sources).tap(&:resolve_remotely!).specs

@indirect: Do you think it is ok to make that change?

Reply to this email directly or view it on GitHub:
#2685 (comment)