This test is not applicable anymore because it tests (and tested) the
wrong thing.
It was to check whether the function failed because the "imag" key
contained the wrong type, but this is not tested by that function. The
function only checks whether the "imag" key is present.
Before we extracted the store configuration from the configuration
toml::Value object and passed it to the store.
This is unecessary overhead.
Now we pass the whole configuration object and let the store extract the
required values.
Before the configuration object (the raw TOML object) was provided via a
wrapper object `Configuration`. This was ugly and not very nice to use.
Now, we only have the `toml::Value` object we lend out from
`Runtime::config()`.
The changes included libimagrt internal rewrites, which are not visible
to the user. Anyways, this change changes the API for config-fetching
from the runtime, so fixes for all other crates may follow.
The changes also removed the support for reading the "editor" setting
from the configuration file, which was not used anyways (in the example
imagrc.toml file).
The CLI-reading and ENV-reading are still supported, though.
Formerly, the --debug flag was ignores. This change overrides the
logging with the CLI specified logging if it was provided.
If --debug was provided, the logging is set to debugging, if --verbose
was provided info logging is used.
Before the iterator did also yield storeids for directories, which was a
bug.
This change introduces a new if_file() function in the store-internal
backend, which is needed to check whether a path actually points to a
File, be it inmemory or on the real filesystem.
That's because tests might fail if they check via PathBuf::is_file() as
in tests, the entries only exist inmemory.
The logger was not able to handle multiple destinations before. Now it
is possible for the logger.
The file must be held behind an Arc<Mutex<_>> so we can use the logging
from multiple threads but also because we need to borrow mutably, so
that bit changes whith this commit.
From the documentation of Walkdir::min_depth():
Set the minimum depth of entries yielded by the iterator.
The smallest depth is 0 and always corresponds to the path given to
the new function on this type. Its direct descendents have depth 1,
and their descendents have depth 2, and so on.
This means that when we started with "/tmp/store", we end up yielding
that exact path in the first iteration. This is exactly what we do _not_
want.
Setting the minimal depth to 1 fixes this bug.
