tox-dev / pipdeptree

A command line utility to display dependency tree of the installed Python packages
https://pypi.python.org/pypi/pipdeptree
MIT License
2.73k stars 147 forks source link

Streamline graph output (graphviz, mermaid, etc.) #349

Open abejenaru opened 2 months ago

abejenaru commented 2 months ago

Describe the feature

Hi, first of all big thanks for creating pipdeptree :)

I was looking into adding support for D2 graph generation, and I think it would be better to avoid adding another output option at this time. Maybe streamlining the current graphviz and mermaid options under a common option (for example --output mermaid, --output graphviz_dot, etc.) and then supporting new formats is a workable enhancement ?

kemzeb commented 2 months ago

Though the D2 project does look fairly new (compared to mermaid and graphviz), I personally wouldn't mind this being added!

Maybe streamlining the current graphviz and mermaid options under a common option (for example --output mermaid, --output graphviz_dot, etc.) and then supporting new formats is a workable enhancement ?

I think this is a great idea too (though we would need to keep the older options for compatibility). We can have something like the following:


$ pipdeptree -h
usage: pipdeptree . . .
. . .
--render       choose how you want to render; this includes mermaid, graphviz-dot, graphviz-png, graphviz-svg, ... (default: text)
--mermaid  (DEPRECATED, use --option instead) . . .
. . .
abejenaru commented 2 months ago

PS. Would adding --json and --json-tree rendering options in there make sense ? For me they are at the same level as graph outputs, but what is your take ? Also, personal preference would be for a 1-letter parameter, like -o --output, as -r is already in use.

kemzeb commented 2 months ago

PS. Would adding --json and --json-tree rendering options in there make sense ? For me they are at the same level as graph outputs, but what is your take ?

Yes, since both --json and --json-tree are rendering options we should include them. To me it would be confusing to see them as their own options but throw the rest within --output.

Also, personal preference would be for a 1-letter parameter, like -o --output, as -r is already in use.

Sure, we can do this instead.