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

added --include and --exclude options #39

Closed
wants to merge 2 commits into from

Conversation

VincentBLortie
Copy link

added --include and --exclude options to set which packages and/or vendors should appear in the graph

@clue
Copy link
Owner

clue commented Oct 8, 2018

@VincentBLortie Thank you very much for working on this! 👍 I agree that this feature makes sense (this seems to implement #33?).

Have you seen the discussion in #33? I'm currently unsure how this is supposed to behave if your dependency graph has a dependency A->B->C and you exclude B. Should this also discard sub-dependencies (C) or should this render two disconnected graph components (A and C)?

@VincentBLortie
Copy link
Author

@clue It doesn't quite implement #33: we don't have a maximum depth parameter, and that could be very useful as well.

Regarding A->B->C with B excluded, I see three options:

  1. Render two disconnected graph components, A and C: it shows that A and C are involved somewhere in the full graph, but the link between the two is missing (not great)
  2. If an excluded package lies on the path between two included packages, it is rendered despite being excluded: it shows all links between included packages, but at the cost of rendering excluded packages
  3. Discard B and any packages downstream (B's dependencies, etc.)

Currently, our implementation of --include and --exclude follows option 1, although I am not convinced it is ideal.

To shed some light on the motivation behind this pull request, our use case involved excluding everything that had not been built in house from the dependency graph. We used --include with our vendor name and a wildcard for the package name. This allowed us to see how our own packages depended on eachother without all the clutter from hundreds of community packages.

@VincentBLortie
Copy link
Author

Perhaps a fourth option would be to render A and C, not B, but to draw an edge from A to C indicating the transitive dependency. Transitive dependencies could be dotted edges, or have some other distinctive feature to make it obvious that they are not direct dependencies.

@clue
Copy link
Owner

clue commented Dec 30, 2021

Thank you for digging into this and filing this PR! 👍

This is kind of an old issue that hasn't seen any activity in a while and the project has changed significantly in the meantime. It looks like the discussion would be best addressed in #11 or #33 first.

The feature request is still open in #11 and #33 and we'll look into this in the not too far future 👍 If you feel this was closed prematurely or want to pick this up again, please let us know and we can reopen this.

Again thank you for your effort nonetheless, keep it up! 👍

@clue clue closed this Dec 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants