This actually caused an error.
When executing `imag ids --verbose trace` for example, the `imag` binary
got the default value (as in `--verbose info`) supplied from clap. So
far, so good. Problem is that the implementation then forwarded that
flag to `imag-ids`, which resulted in the `--verbose` flag to be passed
_two times_ to `imag-ids`.
Somehow this is really strange, but it does not really matter. First of
all: A default of "Info" is still too high IMO. Default should be
warnings and errors, but no information printed. We like silent tools,
don't we?
Second is that the commandline argument forwarding mechanism of `imag`
is broken and this was a fix which helped debugging of the brokenness,
so this is acutally a step forward in this regard as well.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This feature is required for the `imag` binary. It allows the binary to
use the imag internal logger for logging its own log output.
We need to be able to initialize the logger from an external module (in
all imag modules, the Runtime::new() implementation takes care of this,
but as we cannot use that in the `imag` binary itself, we allow this
method to be public behind a feature flag).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
When specifying the `--debug` flag on the commandline, logging was not
enabled. That was because the config file parsing did not consider the
args.
Now, if `--debug` is passed on the CLI, logging is enabled for all
modules and level is set to `debug` for all modules.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
for safely creating a `String` object from `StoreId` which can be shown
to the user.
Mainly introduced because this is useful for error handling (when
putting a `StoreId` into an error kind, the compiler complains that
`StoreId` does not meet the required trait bounds. But `String` does and
we do not process the ID any further anyways).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
The implementation of the in-memory filesystem for testing imag code did
not actually use `HashMap::remove()` when an entry was moved, but
`HashMap::get().cloned()`, which caused the original entry to exist
_after_ the move.
I'm not sure why this did not fail much earlier, but it was clearly
wrong. This commit adjust the test to check the "filesystem" before
checking the store and fixes the bug.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This actually caused tests to fail if there was indeed a file at
/tmp/store/test and the test tried to create a "test" entry in the store.
Do use backend instead to check whether entry actually exists.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
