* 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]
```
When `COMP_POINT` is invalid or out of range, return an empty list of
completions instead of raising `ValueError`. This matches behaviour for
`comp_point < 0 or comp_point > len(comp_line)` cases.
We currently return `@[]` in `splitCompletionLine` when there is
unexpected or unsupported input via environment variables, but let
exceptions during parsing propagate to the caller. Catching those
exceptions allows the caller to use same behaviour regardless of
the nature of unexpected input (either through env, or parsing).
Currently, callers don't seem to be aware of the exceptions, so
going with the behaviour used for environment errors of returning `@[]`.
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.
Etan Kissling
Jacek Sieka
Miran
Etan Kissling
andri lim
ringabout
Vit∀ly Vlasov
tersec
Adam Uhlíř
Vaclav Pavlin
Zahary Karadjov
Kim De Mey
Luke
Ivan Yonchovski
Zahary Karadjov
Ștefan Talpalaru