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

'dotnet nuget why' option to show unique parent packages: --depth 1 #14009

Open
jnm2 opened this issue Dec 18, 2024 · 2 comments
Open

'dotnet nuget why' option to show unique parent packages: --depth 1 #14009

jnm2 opened this issue Dec 18, 2024 · 2 comments

Comments

@jnm2
Copy link

jnm2 commented Dec 18, 2024

NuGet Product(s) Involved

dotnet.exe

The Elevator Pitch

The problem happens when you reference a large set of deeply nested third-party packages that all have common dependencies. When you run dotnet nuget why Microsoft.CodeAnalysis.NetAnalyzers, and get 47,088 lines of output, there's a need for a simplified view.

Skimming this 47k lines in a few places tells me that the package in question is coming from a morass of third-party packages. Now that I know that, I'm left with two questions:

  • How many of the third-party packages are directly referencing Microsoft.CodeAnalysis.NetAnalyzers, so that I can report them all to the vendor? Skimming 47k lines of output to answer this question is not realistic.

  • Are there any other packages besides these third-party packages that also may be causing Microsoft.CodeAnalysis.NetAnalyzers to be referenced? Again, I saw pages flashing by, but I can't be sure that I'm not missing something, and I can't skim 47k lines. I could try to recreate an empty solution structure with only package references and no source files, and try removing this vendor's packages from every project in the solution and running dotnet nuget why again, but that's not nice and quick either.

To address this situation, please consider providing an option that can be used to limit the output so that it displays only the immediate parent packages that bring in the queried package, once per project and target. The output will not explain why the parent packages were included, and this is by design.

Additional Context and Details

As a starting point for design, I would suggest an ancestor depth parameter, so perhaps --depth 1 would provide what I'm requesting here, but --depth 2 might explain all the unique ancestry paths up to two steps removed from the queried package. --depth 2 would still include any one-step-deep paths directly back to the project, with a single intervening parent, as well as any direct references back to the project with no intervening parent.

Motivating image

This is 1/850th of the output. A lovely fractal pattern, which will deduplicate beautifully with a --depth limit option:

@jnm2
Copy link
Author

jnm2 commented Dec 18, 2024

An alternative option could be similar to how https://github.com/KirillOsenkov/MSBuildStructuredLog/wiki/Search-Syntax#nuget-search-projectassetsjson works (thanks @KirillOsenkov!), where each ancestor package is only shown once. Maybe the option could be --simplified, or something like that?

Or perhaps a simplified view could be the default mode rather than dumping 47,088 lines to the terminal?

@nkolev92
Copy link
Member

It was originally added in future possibilities:
https://github.com/NuGet/Home/blob/dev/accepted/2022/dotnet-nuget-why-proposal.md#additional-improvements--future-work

If we have already shown a package's dependencies in the graph in another place, we can truncate the graph at that node and show a (*) symbol to indicate that the package's dependencies have already been shown. We can add a CLI option let users opt-in to this behavior.

I think your issue makes a very good argument for that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants