Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differentiate between top-level gems and transitive dependencies in report #11

Closed
shanecav84 opened this issue Dec 11, 2017 · 5 comments

Comments

@shanecav84
Copy link
Collaborator

When running libyear-bundler, the report can include gems that are not listed in my Gemfile. Those are the transitive dependencies of the top-level gems actually listed in my Gemfile. Often, the updates to those transitive dependencies are reflected in an update to the gemspec of the associated top-level gem, so an update to a top-level gem could allow bundler to resolve using the updated transitive dependency. It's tedious to try and update each gem listed, when an update to just the top-level gems would suffice. I'd like to see top-level gems listed separately (or hierarchically) so I can focus on updating them first.

@jaredbeck
Copy link
Owner

I'd like to see top-level gems listed separately (or hierarchically) so I can focus on updating them first.

I also like to update top-level stuff first. Some people probably prefer to update from the "bottom up", and a hierarchical report would help them also.

Displaying a hierarchy is a bit tricky, because it's actually a Directed Acyclic Graph (DAG) not a tree. We could display a number like "Distance from Gemfile" in the report, where 0 is in the Gemfile, 1 is a direct child, and so on.

Regardless of how it works, this should be off by default, enabled by a CLI flag. We want the default report to be as simple as possible.

However, the focus of this library is measuring freshness, and this feature is getting away from that a bit. We could handle this in a different library, like bunup, or it could be a separate gem
that plugs into libyear-bundler. bunup, for example, could say something like "It looks like you're trying to update actionpack. Would you rather update its parent, rails?"

I think our decision should be based on how much complexity this feature would add.

@shanecav84
Copy link
Collaborator Author

I'll start playing around with a separate library and see what I can come up with.

@jkgraham
Copy link

As a hack you can simply add the bundler option --only-explicit to bundle_outdated.rb here. Might submit a PR for that if I can find time.

@shanecav84
Copy link
Collaborator Author

Some similar discussion is here singlebrook/bunup#11. --only-explicit is Bundler 1.17+.

Copy link

github-actions bot commented Jun 3, 2024

This issue has been automatically marked as stale due to inactivity.
The resources of our volunteers are limited.
Bug reports must provide a script that reproduces the bug, using our template. Feature suggestions must include a promise to build the feature yourself.
Thank you for all your contributions.

@github-actions github-actions bot added the Stale label Jun 3, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants