* Fix `cli` invocation from nimscript
When calling `cli` macro from nimscript, there are compilation issues:
- `nim-faststreams` is not available, therefore, `nim-serialization`
does not work, due to `equalMem` being gated behind `notJSnotNims`.
Dropping support for config files in nimscript contexts fixes that.
- `std/strformat` raises `ValueError` for invalid format strings, but
does so at runtime rather than checking types at compiletime. As it
is only used for simple string concatenation in error cases, changing
to simple concatenation avoids verbose error handling.
- `getAppFilename()` is unavailable in `nimscript`. This was already
fixed by replacing it with `appInvocation()` but two instances of
direct `getAppFilename()` calls remained in default arguments.
This is fixed by changing those default arguments as well.
- The `!= nil` check on the `proc` in `loadImpl` does not work when
called from nimscript. This is fixed by changing to `isNil`.
- Passing `addr result` around to internal templates correctly creates
the config, but the object ultimately being returned is not the same.
Passing `var result` directly through the templates ensures that the
correct `result` gets modified and is clearer than implicit capture.
Applying these fixes fixes running `.nims` files with `cli` macro.
* Add debugging output on failure
* Update confutils.nimble
* Update confutils.nim
* Dynlib fix as suggested in https://github.com/status-im/nim-confutils/issues/31
* Update confutils.nim
* Declare empty commandLineParams if the standard one is not declared.
---------
Co-authored-by: Jacek Sieka <arnetheduck@gmail.com>
The way how `secondarySources` are used in `status-im/nimbus-eth2`,
they call `addConfigFile` again which may raise `ConfigurationError`.
When that happened, loading the primary config file didn't result in
`fail`, which differs in error handling from errors within itself
as opposed to within `secondarySources`. To keep callers concise,
apply same error handling behaviour regardless of whether the error
occurred during primary or secondary sources processing.
Avoid Nim 2.0 warning in callers of `confutils.load`.
```
Warning: 'loadImpl' is not GC-safe as it performs an indirect call via 'secondarySources' [GcUnsafe2]
```
Value parsers are currently allowed to raise `CatchableError`, but in
practice only `ValueError` is raised. Restrict to `ValueError`, and also
properly convert them to `fail` / `ConfigurationError` if applicable.
* suppress unreachable string format errors
We use `%` and `&` to format some strings, which may raise `ValueError`
if the format string is weird. As we are using them in ways that should
always succeed, catch those `ValueError` and convert to asserts.
* add `{.raises: [].}`
The `appInvocation` template in `confutils` is used while showing help,
e.g., before quitting. To ensure that `quit` actually happens, it can't
raise exceptions. Fix that by falling back to `""` on `OSError`.
`writeLine` can fail with `IOError`, and `styledWrite` when using colors
also with `ValueError`. To ensure that the control flow is unaffected,
simply ignore those errors while writing human-readable output to fds.
- The config files processing was not taking into account the `name`
pragma of the configuration object fields.
- The required fields were not searched within config files before
reporting an error that they are missing.
- Fields with the same names were not supported in different case branches
- The loaded config file path can now depend on the configuration
supplied through the command-line.
you can still set the value of a hidden option,
it just dont show up in the help text.
but using `ignore`, the is no chance you can set the value from cli.
line break char: '\n', '\r'
example:
-x, --name regular description [=defVal].
longdesc line one.
longdesc line two.
longdesc line three.
why additional pragma?
- to keep the default value not too far away from the 'name'.
Etan Kissling
Etan Kissling
andri lim
Vit∀ly Vlasov
tersec
Adam Uhlíř
Zahary Karadjov
Kim De Mey
Zahary Karadjov
Hanno Cornelius
Ștefan Talpalaru