-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decouple config spec and type spec #43
Comments
Sorry, I'm not seeing the need for these extra elements. The "decoupling" you mention is precisely the underlying model that is already place. The input to tscfg is a config spec -- as such, all the (optional) "extended" semantics on top of the original type syntax, as well as any optional annotations (as explained in the readme) are processed toward generating the wrapper. Then the wrapper is to be used on actual configuration input. So, the general scenario is that config specs are different from the actual config inputs. However, as explained in the readme, a regular config input could also be used as a spec, in which case:
In this sense, you may have noted that all the spec examples in the code are named with a "spec" fragment ( |
So, continuing with your "application.conf" example, I actually call this |
On the surface, this does seem sufficiently generic, but I have a not-so-uncommon case that I think would benefit from the de-coupling. Let me elaborate. Use case: application.conf: include "application.preprod.conf"
project {
mlJob {
memory = "size | 50G"
lorem = "ipsum"
}
} And I have an preprod {
project {
mlJob {
memory = "size | 100G"
lorem = "opium"
three = "four"
}
}
} The problem is: val cfg = ConfigFactory.load()
// On preprod
val preprodConfig = cfg.getConfig("preprod").withFallback(cfg)
val tscfgMapped = ExampleCfg(preprodConfig) However,
Understandably, this is because the wrapper tries to invoke typesafe's How do I get the correct size-in-bytes conversion at runtime for the preprod configuration? With decoupling, this problem wouldn't occur because the typesafe config itself would not contain the tscfg type spec. It would just contain the values, which I could override easily with any valid value at runtime. Note: I'm not actually doing a size-in-bytes conversion; the use case has been simplified to illustrate my point and support my case. The only workaround I've currently found is to remove all tscfg-specific syntax after generating the wrapper, and add it back every time before I re-generate the wrapper. But this is tedious and I think the decoupling would remove the need for this. |
I think you are actually not separating the two concerns you want to decouple: you are trying to use the same files for both the wrapper generation and their loading at runtime. The typical use of the tool involves the following aspects:
With your example, I would have something like the following: For build-time:
For runtime:
Note: there are of course multiple possible variations of the above depending of how you load your concrete configurations at runtime. This is just to focus on the difference between the two core concerns. (Also, I slightly changed some values just to highlight places where they would be explicitly needed in case of actually overriding the defaults in the spec.) One more comment: we have been looking at an "application" use case in this discussion. But it is relevant to note there's also the "library" use case, in which the developer won't of course know exactly what specific configuration values will be used at runtime. In any case, the general "best practice" is to capture the specification of the configuration schema in a separate resource, from which to generate the code for the wrapper. Then, the runtime aspect pretty much will just follow the regular Typesafe Config mechanisms to loading the concrete configuration, from which to construct the wrapper instance. |
This makes perfect sense, thank you for the detailed explanation and the example! I followed your suggestion, and ended up creating a separate Thank you! |
just added a faq entry in the readme, which points to new wiki https://github.com/carueda/tscfg/wiki/workflow |
Awesome, thanks! |
It would be helpful to decouple typesafe config files from tscfg's type spec. This would help ensure that the original typesafe config is not modified in any way with special syntax that is not recognized by Typesafe Config or any of its other wrappers.
Example:
Before
application.conf:
Instead of specifying tscfg types in this typesafe config file itself, we can decouple the type spec by introducing an optional additional file.
After
application.conf:
tscfg.conf:
Moreover, since all values will now be strings by default unless explicitly converted (#42), the string type specification becomes redundant and unnecessary. The result is a much simpler typespec.
The user can then supply this optional typespec file like so:
java -jar tscfg-x.y.z.jar --spec example.spec.conf --typespec example.typespec.conf
If the user does not specify the
--typespec
parameter, tscfg can look for a defaulttscfg.conf
file in the same directory. If one does not exist, tscfg can proceed with default type conversions (i.e., allString
).Let me know what you think!
The text was updated successfully, but these errors were encountered: