Skip to content

Conversation

@jonsequitur
Copy link
Contributor

@jonsequitur jonsequitur commented Jul 1, 2025

This PR's goal is to separate the CommandLineConfiguration class into two separate classes, one of which configures parsing behaviors (now called ParserConfiguration) and the other of which configures invocation behaviors (InvocationConfiguration). InvocationConfiguration has four properties which were moved over from CommandLineConfiguration:

  • EnableDefaultExceptionHandler
  • ProcessTerminationTimeout
  • Output
  • Error

I've also removed the Parse, Invoke, and InvokeAsync methods from the former CommandLineConfiguration, since they're also available on ParseResult. The redundancy seemed unnecessary, although these invoke methods did include a Parse call, making the calling pattern more like the old, more succinct Command.Invoke methods.

Next steps:

  • In light of these changes, I think both of these classes need better names.
  • I think that passing a RootCommand to the CommandLineConfiguration constructor should not be necessary, and can lead to some unclear situations, such as:
var rootCommand = new RootCommand
{
    new Option<string>("-x")
};

var result = rootCommand.Parse(
    "-x which-root-command-controls-the-parser",
    new CommandLineConfiguration(
        new RootCommand
        {
            new Option<string>("-y")
        }));

@KalleOlaviNiemitalo
Copy link

I was going to comment that a suggest directive or a help action would need to be able to read the parsing configuration at invocation time, such as EnablePosixBundling. But I see ParseResult does have public properties for both configurations.

@jonsequitur jonsequitur changed the title Split invocation-time properties out of CommandLineConfiguration Separate parse from invocation configurations Jul 1, 2025
@jonsequitur jonsequitur marked this pull request as ready for review July 1, 2025 21:40
Copy link
Member

@adamsitnik adamsitnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall it LGTM, but please see my comments with some suggestions for improvements. Thank you @jonsequitur !

@jonsequitur jonsequitur force-pushed the split-CommandLineConfiguration branch from 775d19a to 1f37d7d Compare July 2, 2025 19:40
@jonsequitur jonsequitur force-pushed the split-CommandLineConfiguration branch from c257047 to 24aed51 Compare July 7, 2025 18:21
Copy link
Member

@adamsitnik adamsitnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am hitting the approve button to get you unblocked @jonsequitur , but please address my comment about Invoke before merging. Thanks a lot!

@jonsequitur jonsequitur force-pushed the split-CommandLineConfiguration branch from f3c2633 to faee41a Compare July 8, 2025 17:52
@jonsequitur jonsequitur added this to the 2.0.0-beta7 milestone Jul 8, 2025
@jonsequitur jonsequitur closed this Jul 8, 2025
@jonsequitur jonsequitur reopened this Jul 8, 2025
@jonsequitur jonsequitur enabled auto-merge (squash) July 8, 2025 18:54
@AlexandreEXFO
Copy link

@jonsequitur, @adamsitnik, @jefferson-lam: This change in the contract between 2.0.0-beta6 and 2.0.0-beta7 should be documented as it was when breaking changes were introduced in 2.0.0-beta5.

https://learn.microsoft.com/en-us/dotnet/standard/commandline/migration-guide-2.0.0-beta5

I had to dig into the code to find what had been changed.

@AlexandreEXFO
Copy link

Hope this helps someone who is having the same problem.

Before

await new CommandLineConfiguration(rootCommand).InvokeAsync(args);

After

await rootCommand.Parse(args).InvokeAsync();

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants