choco why/explain

[vbjay]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

No. More a, help us match chocolatey dependency gathering info with our scripts.

Describe The Solution. Why is it needed?

I would love to have a command like choco explain <package> or choco why <package> that shows the depenency tree of why some chocolatey package is installed. Even better if it also included version requirement info to help track down why a package can't upgrade because of other dependency.

Being able to pull the info with the cli would allow us to parse this (Json / xml / tree /A like output?) and understand what chocolatey understands in our scripts and such.

User Story

• As a developer, I want to run choco why <package> or choco explain <package> so I can see which installed packages require it.

• As a build engineer, I want a cached dependency graph so queries run instantly, since repeated choco info calls are slow.

• As a developer, I want to see the full dependency chain so I understand root cause.

• As a developer, I want to know why a package version is constrained so I can troubleshoot upgrades.

• As a developer, I want to test upgrading a package so I can see what would break.

• As a build engineer, I want to identify orphaned packages so I can clean up unused installs.

• As a developer, I want meta-packages (e.g., git vs git.install, dotnet-sdk vs versioned SDKs) to be resolved so I can understand the real install relationships.

Additional Context

No response

Acceptance Criteria

• choco why <package> / choco explain <package> returns all installed packages that directly or transitively depend on the target package
• Dependency graph is cached to avoid repeated choco info calls and enable fast queries
• Cached graph can be refreshed on demand
• Full dependency chain (package → root) is displayed in a readable tree format
• Version constraints are parsed and displayed for each dependency
• Tool identifies and reports which packages are constraining a specific dependency version
• Upgrade simulation (--target-version) reports all blocking packages and their constraints
• Upgrade simulation performs no changes (read-only analysis)
• Orphaned packages (no dependents) are identified and listed
• Meta-packages (e.g., *.install, rollups like dotnet-sdk) are resolved and included in dependency chains (e.g., git ↔ git.install, dotnet-sdk → dotnet-10.0-sdk)
• Output clearly distinguishes between meta-packages and actual install packages
• Meta-package relationships do not create duplicate or misleading dependency paths
• Output is optimized for console readability and CI environments (e.g., TeamCity)

Related Issues

No response

[github-actions]

To vote for this issue, please add a 👍 emoji to the issue description. Votes in comments are not recorded.

[AdmiringWorm]

Thank you for opening this issue, something related to this have been looked at internally before, which is being considered. Unfortunately, at the moment there are no immediate plans to add a dependency graph, but that may change at any point.

I do agree it is something that could be helpful in including, at least in some capacity.