poetry show <package> now also shows which packages depend on it

[snejus]

Pull Request Check List

Partly resolves: #1906

• Added tests for changed code.
• Updated documentation for changed code.

#1906 Requested an ability to know why packages are required. Even though the suggestion outlined a reverse-tree based approach, I believe that this can also be solved using a more simple approach: by providing the required by information in the poetry show <package> output - done with just 15 lines of code.

I had this patch applied locally since a couple of weeks ago and I found it extremely useful - there's no need to do poetry show --tree | ag <package> -C 20 anymore just to find out where some 3rd party dependencies come from.

Summary of what's been done:

• 15 lines of business logic in commands/show.py
• A test for poetry show <package> command - realised a test for this command didn't exist, so it tests both the default output and my changes
• Documentation update and a little typo fix, where dependencies isn't supposed to have a colon at the end.

Please see the screenshot below for a little teaser:

[snejus]

Can include this as an extra if anyone's keen ;)

[seansfkelley]

Looks neat! Does this traverse the ancestry all the way to the root pyproject.toml, or just one level up from the specified package?

[snejus]

@seansfkelley - it's the latter, it only specifies direct dependencies.

I guess the reverse-tree approach would be more suitable for the traversal, which personally I find a bit too noisy, at least for the workflow I'm used to (maybe I just haven't tried a good solution though) - there's actually a PR open that aims to do it: #2086, though it has been stale for a while, so it'd be great if people could have a look at it since it looks quite promising.

The required by in poetry show removes the noise and simply tells the dev hey, that's the list of libraries that use it and they specify these constraints - and yeah, now you see which one of those constraints restricts you from bringing that new feature in. I find it very useful whenever I need to integrate a minor/major bump coming from 3rd party dependency - I see whether it's supported or blocked in a simple way. I found that I'm usually aware of my project dependencies enough to kind of know where they're coming from considering higher levels - it's the versions that cause pain :) There's always an extra pip show <parent-package> command available otherwise.

The reverse-tree, I guess, has a different use case. One I could think of would be analysing bigger open source projects that devs are new to. poetry install -vvv -> sees a dodgy package -> ah where did this come from? -> runs poetry show --tree --reverse <dodgy-package> (or --why, as in the PR above) -> sees a nice overview of what's going on.

Actually, pipdeptree has implemented it in a way, see a screenshot below for six usage within poetry:

And then poetry show six - obviously it's an unfair comparison considering the looks 😅

[snejus]

Forgot to mention - pip implements the show command too - though since good looking or dependency management aren't exactly the keywords usually associated with pip, it's only useful as a backup.

[seansfkelley]

Great, thank you for the explanation! pipdeptree looks quite handy.

My usual use-case for needing to answer this question is that I've traced an issue through debugging to a particular package, and I want to know which of the dependencies I've declared is bringing it in so I can take (indirect) action to resolve the problem, usually by picking a better version for my dependency or seeing if I can just remove it. All that is to say -- it doesn't come up during version upgrades, so I don't have anything else to narrow down which packages are suspicious.

In any case, this change would already make my life easier, even if it's not exactly what I'm looking for.

[snejus]

@sdispater could this by any chance go in, considering that it's very small and has virtually no impact on the rest of the codebase? It's been a couple of months now that me and most of the people around who use Poetry, patching the releases with this - I even have a little bash function that does it. It's extremely useful for bigger projects.

[K900]

Just another bump/upvote for this. Very interested in this.

[finswimmer]

Hello @snejus,

I really like this one. Would you find some time to rebase your PR onto master?

fin swimmer

[sonarcloud]

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
9.6% Duplication

[snejus]

@finswimmer sorry, was a bit in a rush and forgot to switch the base branch. Is there anything else that's required from my side?

[finswimmer]

I'm very sorry to ping you again @snejus. For some reasons the SonarCloud Code Analysis failed. We removed this check for now. So could you rebase once more?

[snejus]

of course! :)

[finswimmer]

Great 👍

[spirit-q2]

@snejus, @finswimmer, I wonder, what are the reasons for not putting this feature into 1.1.11?

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.