Adding pipdeptree's functionality to pip code base

What’s the problem this feature will solve?

Hi.

I am the author and current maintainer of pipdeptree and I wanted to check if pypa org / pip’s maintainers would be open to the idea of adding pipdeptree’s functionality to pip itself.

The current use case of pipdeptree is to render a graph of dependencies, and for that it uses pip’s code (yes, import pip, I know).

The current state of pipdeptree borders on “unmaintained” because, (1) I am not finding time for open source work lately due to personal commitments and (2) python is not my primary language at work any more, so I am not up-to-date with the recent developments in the python/pip ecosystem.

The original use case of pipdeptree was to make tracking down of conflicting dependencies easy. I believe conflicting dependencies is no longer a problem on newer environments thanks to the new dependency resolver. But people seem to be still using it, either for older envs or for it’s graph output.

One problem with pipdeptree since the beginning has been it’s dependence on the internal functions of pip. So every time there’s an internal refactor in pip, a “stable” version of pipdeptree can potentially break. I was fully aware of this right from the start but the script did solve a problem for me and others at that time (2015). As the project became more popular, I (with the help of contributors) continued to keep the code up-to-date with latest pip versions, and even backward compatible with older pip versions.

Describe the solution you’d like

If pip is interested in the graph output functionality of pipdeptree, I propose the code (under MIT license) can be moved inside pip and provided as a subcommand. This will ensure that,

1. There are no breakages due to internal refactor (considering that pipdeptree would also be “internal” to the repo)
2. The community can maintain it in a more timely manner

As I mentioned above, pipdeptree uses import pip under the hood and the core functionality of constructing the dependency tree is decoupled from the CLI. So I believe it should be straightforward to move the code without many changes.

If this proposal gets approved, I can help with moving the code to pip in whatever way possible.

Alternative Solutions

Another option for me is to find a maintainer and transfer the ownership of the repo on github and pypi.org. However, the possibility of having to fix pipdeptree after pip releases remains.

Additional context

Something similar was proposed earlier (long ago)

• https://github.com/pypa/pip/pull/2329
• https://github.com/pypa/pip/issues/8077

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[sbidoul]

@stonebig the packaging library has everything to parse requires_dist correctly. Each item is a Requirement, then you can use requirement.marker to evaluate if it is applicable to the environment and extras.

[pfmoore]

They’re still visible as regular Python packages, with dist-info or egg-info, last I checked, so it should “just work”.

In this context, I think the problem is that any new library would need to duplicate pip’s logic for reading the “old-style” files to get the location of the project (as there’s no direct-url.json file). But as I said, that’s just a bit of extra work.

Is there anything actionable here, on pip’s end?

Nope.