Add support for custom interpolation lookup strategies

[ahrytsiuk]

As a developer, I want to add custom interpolation lookup strategies for option default value.

Currently, interpolation strategies are hardcoded in the picocli.CommandLine.Model.Interpolator class. And have the following options:

• sys:
• env:
• bundle:

It would be nice if I can add/register my own strategy. For example when developing Spring Boot application - I want to be able to use the standard Spring Boot configuration mechanism to populate option values.

Let's imagine the following code sample:

       @CommandLine.Option(
            names = "--server-url",
            required = true,
            description = "Server base path URL",
            defaultValue = "{spring-env:server.base-url}"
        )
        public void setBaseUrl(String baseUrl) {
            this.baseUrl = baseUrl;
        }

I expect the default value for this option to be populated from the Spring Boot Environment, if it wasn't specified in the CLI arguments.

And of course, I have to provide the implementation for such a strategy by myself.

[remkop]

@ahrytsiuk Interesting idea. Will you be able to provide a pull request for this with thorough tests and documentation?

[ahrytsiuk]

@remkop sorry for the late response. Yes, I can provide a PR. However, I want to check with you a direction on how to implement this.

I was thinking about this:

• make ILookup interface public
• and add method addInterpolateLookup(String, ILookup) into CommandLine class and builders.

WDYT?

[remkop]

Yes, that looks good. Some other things I noticed (there may be others):

• the ILookup interface is nested in the CommandLine.Model.Interpolator class. I don't think that the Interpolator class should become public. So, ILookup needs to move. Not sure yet whether it should stay under Model or go directly under CommandLine.
• the ILookup interface currently does not have any javadoc explaining its intended usage and what the responsibilities are for implementors. When made public this documentation needs to be added.
• the ILookup interface's method is called get. Maybe it should have a name that communicates its intent better if this interface becomes public? (Maybe the current name is fine. Let me know your thoughts.)
• the UsageMessageSpec class only has one public constructor, and that constructor sets the Interpolator field to null. Does the other constructor also need to be made public? (UPDATE: looks like maybe not; the CommandSpec's UsageMessageSpec is never replaced, only modified via the UsageMessageSpec.initFrom methods, so the interpolator field remains unchanged.)
• about the method for adding custom lookups: how about using the method name addInterpolationLookup(String, ILookup)? (other ideas welcome, some other ideas I had were: addVariableInterpolator(String, ILookup), addVariableInterpolationLookup(String, ILookup), ... )
• do we need to also add removeInterpolationLookup(String key) together with the addInterpolationLookup(String key, ILookup) methods?
• this addInterpolationLookup method should be added to both CommandLine and CommandSpec, with different semantics: adding it to CommandLine means the lookup is added to that command and all the subcommands that this command has at that moment, whereas adding a lookup to a CommandSpec means that the lookup is only added to that command (and not to any subcommands). This is consistent with the other setXxx methods on CommandLine.

[remkop]

FYI: For testing the difference between adding a lookup to a CommandSpec vs adding it to a CommandLine instance, there are similar tests in SubcommandTests.