Closed teroz closed 4 years ago
Yes, this package is guilty of following a README-driven development. Some of the advertised features are not ready yet. If you definitely need to use config files, I can offer guidance for implementing them yourself. Otherwise, I expect the implementation to be started in the next few months.
😂😂 I see. Yes please, pen me down your thinking and I can take a stab at it.
On Fri, Dec 20, 2019 at 4:11 PM zah notifications@github.com wrote:
Yes, this package is guilty of following a README-driven development https://tom.preston-werner.com/2010/08/23/readme-driven-development.html. Some of the advertised features are not ready yet. If you definitely need to use config files, I can offer guidance for implementing them yourself. Otherwise, I expect the implementation to be started in the next few months.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/status-im/nim-confutils/issues/13?email_source=notifications&email_token=AAGQOVXGZDNVEL5UWYUTNMDQZTHAXA5CNFSM4J5IZQQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHNAS6Q#issuecomment-567937402, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGQOVXVGF6TXUVNQR5P74DQZTHAXANCNFSM4J5IZQQQ .
--
I'm sorry for taking so long to reply, but here is a rough sketch:
The long term vision here is that Conftuils should provide a low-level operation loading a list of config files with increasing priorities (for example, a system-wide config with defaults and a shorter user-specified config with overrides; or a git-style system where the config files can override properties on a directory-by-directory level).
This low-level operation will work with any format supported by nim-serialization, a library whose main idea is to provide a common generic interface for different formats in a way such that the Format itself can be considered a generic parameter (you'll see for example how nim-serialization defines a generic test suite that can work for any format).
Many formats can be viewed as a sequence of key-value pairs (e.g. json, yaml, toml, proto-buf) and these will be a perfect fit for use with confutils. Since the configuration is represented by an object, you can start with a default value and then rely on the serialization readers' ability to load data into an existing object:
https://github.com/status-im/nim-json-serialization/blob/master/json_serialization/reader.nim#L144
You would do that for each config file in turn. To specify the list of config files, you'll add a tuple of TypedInputFile
values as a parameter to the load
function. The Format
parameter of the typed input file will allow you to instantiate the right reader type (you'll find examples for this in the generic test suite above).
These initial steps will be rather simple, but the majority of the work here lies in implementing the support for more formats as nim-serialization packages. It would be lovely to implement TOML or YAML for example.
I would approach this by studying the existing nim-json-serialization package and its test suite. Large portion of the code there was taken and adapted from Nim's standard library json module. Where nim-serialization differs is that all input and output is based on our nim-faststreams package which offers a faster and more versatile API for working will different kinds of streaming inputs.
I usually start by taking the lexer of an existing package with the goal of adapting it to use nim-faststreams. Then I write a reader and writer module that is able to use the lexer to directly load the data into strongly-typed Nim objects without any intermediate steps.
Hey @zah thanx for your thoughts. I had hacked something usable together but then found https://github.com/c-blake/cligen which met my needs and has alot of good work into it already. So I just ended up using that
The description above can serve as a reference for anyone interested in trying to implement this under our bounty program
closing, fixed by #26
I like this package it works nicely as advertised except for the config file. As far as I can tell it doesn't automatically load a config file as described in the README and TypedInputFile which would be used so specify an explicit one in an object property gives a compile time error TypedInputFile is not a concrete type - what? The README also talks about a ConfigFilePath[Format] which is not referenced anywhere
How can I specify a a config file to be loaded? Am using nim 1.0.4