-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[main] Update dependencies from dotnet/command-line-api #33126
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
[main] Update dependencies from dotnet/command-line-api #33126
Conversation
…uild 20230608.1 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.430701 -> To Version 0.1.430801
|
@jonsequitur Looks like dotnet/command-line-api#2205 changed the namespace name "CliAction" caused an error, could you take a look? |
…7233ddc-4b19-4004-b583-4a3b720def80
…uild 20230612.1 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.356401 -> To Version 0.1.431201
…uild 20230612.2 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.356401 -> To Version 0.1.431202
|
@jonsequitur Could you take a look at the error here? The build is failing because of missing assembly reference. |
…uild 20230615.1 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.356401 -> To Version 0.1.431501
…uild 20230619.1 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.356401 -> To Version 0.1.431901
…uild 20230626.1 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.356401 -> To Version 0.1.432601
…7233ddc-4b19-4004-b583-4a3b720def80
|
@adamsitnik @baronfel can you take a look as it looks like the underlying code for CliAction changed here and I'm not sure what the update should be. |
…ynchronous Invoke was not called. Removed uses of EnableParseErrorReporting and EnableTypoCorrecti since these were removed from CliConfiguration. Set the Directives on CliRootCommand since CliConfiguration no longer has a local list for Directives.
|
@jonsequitur Can you review the changes I made in my commit above? I based the adjustments from the breaking change PR that you did for S.CL. |
…7233ddc-4b19-4004-b583-4a3b720def80
|
Looks like there's a test failure where missing a required parameter prints out the usage output but it missing some pieces. Not sure why some of the usage is missing and the arguments are fully missing. Odd change in behavior. Usage: Arguments: |
|
@jonsequitur @adamsitnik Did some debugging. Looks like BeforeThe You can see the The weird part for me is when I try to add a breakpoint to the setter for the AfterThis new implementation doesn't seem to set the |
|
The issue was identified to be the one reported here: dotnet/command-line-api#2226 |
|
There was a fix merged for this issue. We'll have to wait until a new version is published. dotnet/command-line-api#2249 |
…uild 20230731.1 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.430701 -> To Version 0.1.438101
…uild 20230807.1 Microsoft.SourceBuild.Intermediate.command-line-api , System.CommandLine From Version 0.1.430701 -> To Version 0.1.440701
|
Current Progress: Waiting for this change to fix the current test failures for the Edit: That change was merged but a new S.CL package hasn't been published since Aug 7th. Disabling that check in the test for the time being. |
…selves. There is potential for this simplification to cause issues, but at least the build works now.
… on a new S.CL package version.
…es. But contains commented code of other variants.
…ges. The logic around OptionResult was required or else it would both show the warning and try to use -p as a property (when it should be a project) for the particular failing tests.
|
Passing checks, is this actually ready finally? Not sure how to review the changes given they are in response to S.CL changes. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This is ready. Looking in DARC, here are the repos that dotnet/command-line-api flows to:
We'll need to coordinate so that there is only 1 version of S.CL for source build to use. I'm not sure how to do that. Any suggestions? |
|
Hmm, I think we need some guidance from @MichaelSimons as I think the coordination was specifically driven by source build. The runtime makes this hard to do outside of main (ie we may have to leave 8.0.2xx untouched unless we want to take a servicing change to 8.0 and 8.0.1xx) Can we get PRs triggered for each of those repos in main? Roslyn main will flow to 8.0.2xx so I'm not sure how to make this work. |
| HelpBuilder.Default.CommandArgumentsSection()(context); | ||
| context.Output.WriteLine(); | ||
| HelpBuilder.Default.OptionsSection()(context); | ||
| context.Output.WriteLine(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity why was this newline needed? Did formatting change upstream or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It did. The help output logic was changed and normalized. As you can see, previously, every other section here had an added WriteLine added to it except this one. It was likely being added (by accident) in the previous versions of S.CL.
I had to add it here so that the tests for checking help output passed and remained the same as expected.
| public static CliConfiguration Instance { get; } = new(ConfigureCommandLine(RootCommand)) | ||
| { | ||
| EnableDefaultExceptionHandler = false, | ||
| EnableParseErrorReporting = true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we remove the error reporting here and in the other place? S.CL uses this for reporting parse errors in a nice way - I'm actually pretty confused why our tests pass with such a large change!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feature was changed and this property no longer exists on this class. There is a discussion here that you responded to. This concept is bound to the ParseErrorAction now. From my understanding, it isn't a thing you turn on/off, but the type of action returned when a parsing error occurs. It is actually one of the things I've made a PR for, as there was a problem with a stray newline in its output: dotnet/command-line-api#2289
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow I completely forgot about both of those things 😅
Thank you for the reminder, and the explanation! All good from my end now.
|
Created PRs for the other repos to update the S.CL version: SDK PRNew PRs
Already has latest S.CL version
|
|
The changes have hit dotnet/installer#17818 so we won't get a new installer until all the prs have merged and completed flow into sdk |





This pull request updates the following dependencies
From https://github.com/dotnet/command-line-api