Add a filter to not display all dependencies from whole graph

[pscheit]

My graph is just to large. I want to use it for documentation purposes and don't want to show up third party graph-nodes.
So a regular expression filter would help me here.

Would you merge this?

Best regards
Philipp

[clue]

New additions (and mere ideas) are very much appreciated!

I think it certainly makes sense to add this feature. Perhaps it should be generalized as to accept a --depth={N} option? So in your case, you'd probably want to supply a --depth=1.

[pscheit]

jeah, i thought for depth as well. But I have dependencies in my graph that are sub dependencies, which i want to display.
Basicall i really want to filter with /webforge-(.*)/

[clue]

Duh, totally missed your reply, sorry.

Now I see where you're coming from. Filtering on an arbitrary parameter is significantly more complex as you have to consider what happens with intermediary dependencies like this:

A -> B -> C

So if you only keep A and C (i.e. filter out B), you might either want show

A -> C

or just

A C

which dependending on your use case might both be incorrect.. I'm interested to see what you come up with, though.

Would you merge this?

Certainly yes! :)

[radanisk]

👍

[markuspoerschke]

Some other thing that could make the graph more readable would be removing the require-dev dependencies. In our case every package depends on PHPUnit and PHP. This could easily be dropped. Maybe we can add a parameter to ignore dependencies also by require-dev?

[bishopb]

@markuspoerschke 👍

[clue]

Maybe we can add a parameter to ignore dependencies also by require-dev?

Thanks for your interest guys! Hiding dev dependencies is discussed in #2 (and a pending PR #19).

Afaict this tickets aims to find other, alternative ways to "filter" the dependency graph - though I'm not sure how this could/should work (see above for some background).

Any input is much appreciated!

[bishopb]

I would want to see a --prune <package> option, which removes that package and all of its dependencies from the graph. Simultaneously, any packages affected by the pruning would have a visual marker indicating they're not 100% complete. Example:

Initial state    --prune D   --prune C   --prune B   --prune A  --prune A --prune D
==============   ==========  ==========  ==========  =========  ===================
   A     B         A    B*    A*    B    A                B              B*
   |- C  |         |- C*            |    |- C             |
      |  |                          D       |             D
      D--|                                  D

The asterisks represent the visual indicator. On the graph, it could be a dotted border, a lighter hue, etc.

Show/hide dev dependencies is just a special case of this general instrument. If my require dev is phpunit, behat, and athletic, then that's equivalent to --prune phpunit --prune behat --prune athletic.

Admittedly, I haven't considered all the ramifications or possibilities. We might not allow --prune to fragments the graph into multiple "islands", as explained in this research paper, § 3.2. However, we might offer a --prune-force override to really do this.

I personally do not mind if the graph generation takes more time, if by spending that time I can get a graph that's more relevant to what I need to visualize.

[addshore]

+1 I would love something like this!

[bishopb]

@clue I can put some cycles on this (though with no guaranteed delivery dates!).

What do you think of the --prune API mentioned earlier?

How about an approach like PHP Dependency Analysis, which uses "levels" to decide how deep to descend?

[NiMeDia]

Thought about implementing this with the --prune (or --exclude) command like @bishopb mentioned above, just don't know how to handle the PR from #19 which would potentionally conflict with this issue.

[bishopb]

@P0rnflake, Isn't --dev equivalent to current behavior and --no-dev a convenient shortcut to the equivalent prunes (--prune dev/dep1 --prune dev/dep2 ... --prune dev/depN)?

If so, then the CLI API and feature from #19 could be merged in, then when this issue is implemented, just rewrite that API to use prune. That wouldn't have any BC to the user, but it might abandon all the work from #19 in favor of the general prune approach.

[clue]

Thanks for the discussion so far everybody 👍

I'd love to make this actionable and get this into a future release

As such, see also #33 which aims to implement a (much simpler) --depth option.

Does anybody feel like giving an implementation that prunes/removes certain dependencies a go? Perhaps this may help sort out the remaining uncertainties.