SubCommand values from app.config

[btrepp]

Description

What is the syntax for specifying values /arguments for subcommands in the app.config file?. It may not be supported for subcommands, but I can't concretely find this in the documentation.

Repro steps

type SubCommand1 =
         | Nested of string
with ...

type MainArg =
     | Command of ParseResults<SubCommand1>
with ...

app.config
...
<add key="nested" value="hello">
<add key="command.nested" value="hello2">
<add key="command nested" value="hello2">
...

Expected behavior

When running app.exe command nested would be either 'hello' 'hello2' or 'hello'3

Actual behavior

Argu reports that nested was not provided

Known workarounds

Put all arguments into MainArg rather than scoped to the subcommand

Related information

[haf]

This I could use.

Another workaround:

let maybeSubcommand (argv: string[]): string[] =
  let found = ConfigurationManager.AppSettings.["subcommand"]
  if isNull found then argv else
  let subCmdArgv = ConfigurationManager.AppSettings.[found].Split([| ' ' |], StringSplitOptions.RemoveEmptyEntries)
  [| yield found; yield! subCmdArgv; yield! argv |]

[gusennan]

@haf How does this workaround work?

[haf]

It uses subcommand to look up the other key to read, and then parses that by splitting on space and prepending both the subcommand and its child arguments to the initial argv array with the remaining commands from command line. @gusennan

[gusennan]

I see, thank you.

[bartelink]

Wondering if this should be closed?

Ideally, to my mind, a long-lived issue should reflect either:

• a major gap that is an obviously complementary and valuable thing, even if realistically there's nobody that's going to implement it in the short/medium term
• something that everyone wants but for now the solution is a workaround

For me, this falls between the two stools:

• obviously the participants here wanted it
• but it doesn't seem likely to end up being resolved, as there is no sign of a fully fleshed out feature proposal that would be implementable.

I'd love to get to the point where the impetus of #191 lets us get to a shorter issues list with up-for-grabs and/or good-first-issue tags can go on things and we start working in smaller chunks collectively rather than remain in stasis.

i.e. a vague issue like this might make sense if an Eirik was eventually going to resolve all the forces, but for now it's just a feature idea that makes it harder for the average newcomer to traverse the issues list to get an idea of

1. open bugs/real issues
2. sutff they copuld maybe help with

@btrepp would you agree with closing the issue and waiting for it to resurface/be re-opened if this re-arises?

[bartelink]

Closing pending this becoming actionable. Zero objections to it being re-opened when it's more focused, but I'm having trouble bucketing it as it stands