"Dynamic parameters" support?

[sschuberth]

Is there support for dynamic parameters in clikt, or something that comes close to it? Note that in the -Da=b -Dc=d example there's no space between -D and a, which generally is something that is not support in clikt, AFAIK.

[ajalt]

That's not currently possible with Clikt, since it would require changes to the parser.

Can you share your use case and (if you know of any) existing apps that use dynamic options?

[sschuberth]

E.g. Gradle uses that type of option to pass system properties or project properties on the command line, and I believe Maven has the same (at least for -D). My goals was to resemble that feature in my own project.

[ajalt]

So looking into Jcommander and gradle's -D (and -P) options, I think Jcommander's choice to call them "dynamic options" is a bit misleading.

In gradle, all of the following are equivalent:

-Dfoo=bar
-D foo=bar
--system-prop=foo=bar
--system-prop foo=bar

So it's not that the option is dynamic. It's parsed the same as any other option, it's just that the option's value has an = in it, which is used to create a map entry.

You could do that easily with transformAll now if you use a different separator than =.

This works for all of the above examples except the first one:

option("-D", "--system-prop").transformAll { all ->
    all.associate { v -> v.split("=").let { it[0] to it[1] } }
}

-Dfoo=bar is currently parsed as a long option, but it would be easy to fix that.

So we could do something like option().keyValue() that implements the above transformation pretty easily. Let me know if you have a suggestion for a better name.

There are some potential additional features that could also be added:

• Omitting values (-Dfoo=bar -Dbaz)
• Value conversion
• Customizable delimiter (e.g. foo:bar instead of foo=bar)

[sschuberth]

I think Jcommander's choice to call them "dynamic options" is a bit misleading. [...] So it's not that the option is dynamic.

Absolutely correct, and I agree the name is misleading (and somewhat promises more than what it actually does).

-Dfoo=bar is currently parsed as a long option, but it would be easy to fix that.

That would be great!

So we could do something like option().keyValue()

I wonder if it makes sense to generalize pair() instead by taking a delimiter which would be set to = in this case.

There are some potential additional features that could also be added:

All of these would be nice to have! Omitting values is a common thing e.g. in Maven with -DskipTests (there's no need to set it to true as the presence alone already expresses that). Value conversion is probably not that important, that could be done in regular code later if needed. But being able to customize the delimiter would be beneficial, I believe.