Make CLI parser public for dotnet nuget why #6118
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jeffkl
approved these changes
Oct 24, 2024
nkolev92
approved these changes
Oct 25, 2024
Member
nkolev92
left a comment
There was a problem hiding this comment.
I love this, it's what I'm hoping we can do for all of our commands in NuGet/Home#13089.
I think it'll make our lives easier long term!
Well done @zivkan!
martinrrm
approved these changes
Oct 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bug
Fixes: engineering issue
Description
Running
dotnet nuget whywithout a directory, solution, or project file reports an error saying that a required argument is missing:But you'll notice that the command ran anyway.
The reason is that the dotnet/sdk repo has a duplicate set of CLI parser definitions to enable tab-completion. There was previously a bug, which required the target to be supplied, but #5969 fixed it by making it implicit. However, the dotnet/sdk's duplicate definition was not updated to contain the same change.
Since
dotnet nuget whyis using System.CommandLine, rather than duplicating the same change in the second repo, I intend on making dotnet/sdk use the new public API introduced by this PR, so that NuGet.Client will be a single source of truth for how to parsedotnet nuget why. It will also mean that why will run in the dotnet CLI's process, rather than the NuGet.CommandLine.XPlat child process. But this is our long term plan with migrating to System.CommandLine anyway.So, this is step 1, create a public API that the dotnet CLI can call. Once this change has been inserted in the dotnet/sdk repo, I can create a PR there to delete their WhyCommandParser and call this instead.
Alternative
I investigated moving the logic of invoking NuGet.CommandLine.XPlat as a child process into NuGet.Client, and also all the NuGetCommandParser definitions from the dotnet/sdk repo here. However, it was looking to be a lot of work, and I want to get this CX bug fixed more quickly.
If the team feels strongly that we shouldn't create the "temporary" public API, I can focus more effort on this.
I did however create #6117 as a first step towards making it easier to move all that dotnet/sdk code into NuGet.Client. Whether or not that PR gets accepted has a big impact on how to implement the rest of the move of
dotnet nugetparser out of the dotnet/sdk repo and into here.PR Checklist
and a linked NuGet/Home issue(no product changes, it's more of a refactoring change)Added testsit will be covered by the existing Dotnet.Integration.Tests once the change is commit in the dotnet/sdk repo.Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.no customer facing changes.