Get result of parsed command line arguments as an object

[Mirandatz]

trafficstars

Is your feature request related to a problem? Please describe. Yes, I would like to have an "CommandLineArguments" object with immutable fields that I could pass around my application.

Describe the solution you'd like Instead of using int CommandLineApplication.Execute<ProgramSettings>(args); I'd like to have a method ProgramSettings ParseCommandLineArguments<ProgramSettings>(args); so that I could pass "Program" around.

Describe alternatives you've considered Currently, I'm doing the following Program.cs contains the entry point of the program and the following code:

public static int Main(string[] args) {
	if (args.Length == 1 && args[0] == "--lazy-dev-switch")
		args = LazyDevArguments();

	return CommandLineApplication.Execute<ProgramSettings>(args);
}

private static string[] LazyDevArguments(){
...
}

public static int Run(ProgramSettings settings) {
	... DoStuffWith(settings);
}

It is ugly, but at least it allows me to pass a well-formed "ProgramSettings" object around.

And in ProgramSettings.cs I have all the Options and whatnot PLUS the method OnExecute():

public int OnExecute() {
	return Program.Run(this);
}

[natemcmaster]

So, in other words, you want all the goodness of CommandLineApplication.Execute<Settings> without the requirement to implement an OnExecute method on the Settings class? If so, this is something I've considered adding but was basically waiting to see if anyone actually wanted it.

[Mirandatz]

Yep! And I feel like you already did all the heavy work, instating Settings, parsing and setting its fields with reflection and wizardry.

I feel like it's going to be a easy feature to add; just returning the created object (Settings) instead of invoking OnExecute.

[kyle-rader]

It seems like this would also help some bootstrapping problems, such as needing too instantiate a logger with a verbosity but the verbosity value is passed as an option.

Would this basically give you the parsed args before setting up services with DI and calling execute?

On Wed, Sep 4, 2019, 5:08 AM Mirandatz [email protected] wrote:

Yep! And I feel like you already did all the heavy work, instating Settings, parsing and setting its fields with reflection and wizardry.

I feel like it's going to be a easy feature to add; just returning the created object (Settings) instead of invoking OnExecute.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/natemcmaster/CommandLineUtils/issues/270?email_source=notifications&email_token=ABEI7XE7CLJ3BXQWN3PCF4LQH6QJ7A5CNFSM4ISTVLH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD53K6WY#issuecomment-527871835, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEI7XBYVPYUXGQ3APQ222LQH6QJ7ANCNFSM4ISTVLHQ .

[Mirandatz]

@kyle-rader Sorry, I don't know what DI stands for.

[natemcmaster]

Dependency injection.

Yeah, the heavy lifting is done. This is really a matter of designing an API that works well. It's possible to implement some of this on your own with CommandLineApplication and an empty OnExecute (see example here) but this is more effort than I think should be necessary.

I've wanted to expose a lower level API that parsed args into a simpler dictionary-like result first. Then this result is bound to an object or the CommandArgument/Option types. I nearly wrote it into this library last year, but ended up helping the team that wrote System.CommandLine build this approach instead. I've been tempted to use it as the "processing engine" under the hood, but System.CommandLine doesn't appear to be on track for a stable release anytime soon. So, I'm thinking maybe I should do it on my own instead.

[Mirandatz]

Oh my, yes. This surely would help with dependency injection.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please comment if you believe this should remain open, otherwise it will be closed in 14 days. Thank you for your contributions to this project.

[github-actions[bot]]

This issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please comment if you believe this should remain open, otherwise it will be closed in 14 days. Thank you for your contributions to this project.

[github-actions[bot]]

Closing due to inactivity. If you are looking at this issue in the future and think it should be reopened, please make a commented here and mention natemcmaster so he sees the notification.