Open rivasdiaz opened 3 years ago
/cc @ebullient, @gsmet, @maxandersen
I've been thinking about this, too.
I'm thinking we have a few options:
I personally would like to disable the runtime processing of application.properties and .env files entirely (ignore them) when working with a CommandMode/CLI application (using picocli or not). I want to rely on picocli commands for injection of config values entirely, as there is no reliable application.properties to read from at runtime. (The Quarkus CLI doesn't use application.properties at runtime at all, everything is picocli parameter based, but I can understand why you need to bridge into an expected/existing config system.. )
We could allow an alternate source file to be specified out of the box, but as you mention, this won't show up in picocli help. We might be able to work around that with clever codegen or automatic registration of a mixin (e.g.) that would bridge the gap.
I definitely see uses for application.properties
and .env
files on a CLI app.
I can add to my main application.properties
all settings I don't need user input for, and that file will end either inside an uberjar or processed while building a native binary. For .env
files, although I haven't used them with quarkus, at work we have a couple of python cli tools which store some properties (that are global for the user) in .env
files and I have found that functionality useful.
That said, I expect having support for a ConfigSource (or similar mechanism that lets me configure quarkus components) on top of command line options to be way more valuable for CLI apps than a ConfigSource for application.properties
so if the later were blocking the former, personally I would be happy with a special configuration support on CLI apps even at the cost of disabling all other modes.
To be clear: application.properties would still be read/used at build time. I am specifically talking about implicit/assumed runtime processing of application.properties or .env files (as that applies to running a command line application from an arbitrary location)
Description
I would like to be able to map parameters parsed for a picocli command to config properties. The simplest case would be to have commands available as a configuration sources.
Use case:
Allow the developer to specify host, username and/or password for a database connection to be parameters, which may have (in some cases) predefined defaults.
If I use Quarkus Database support, the username and password should be defined as properties and I can't override the property once the Picocli command is parsed. I attempted to define a ConfigSource backed by a map in memory and populate from the command implementation, but by the time the Picocli command is instantiated, the Config Sources are already instantiated. I also attempted modifying a system property from the Command which doesn't work either.
Currently the solution I found was defining a new property, for example
username
, then define in myapplication.properties
the following propertyquarkus.datasource.username=${username}
. The user can then pass-Dusername=<username>
to the application. This approach works, but doesn't show up listed by--help
and is not the most common form which could be using--username
or-u
.Implementation ideas
Ideally a Quarkus application using the Picocli extension would define config sources for each defined command, probably opting-in with an annotation. This annotation may also define a prefix for the introduced properties.
An example:
}
Finally, by using advanced support in picocli, a developer could validate or transform the user specified parameters. For example instead of defining the
logginglevel
, the option could beverbose
, and with the help of a converter, transform the input to the valuesINFO
orWARNING
. This way the user of the cli could specify--verbose
instead of--logging-level=INFO
.