Because the code was so complex before, we had to create an object and
then cast that object into a `StoreId` rather than just creating a
`StoreId` object right away.
With this patch, we're using the code-generation approach to generate a
function that creates a `StoreId` object based on the name of the
current module. That's way easier and error handling was also improved
by the switch to the new implementation.
The patch also includes a rewrite of all usages of ModuleEntryPath and
changes them to `module_path::new_id()` calls.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
The beta compiler reports duplicated input:
error: the item `IntoValues` is imported redundantly
--> lib/entry/libimagentrylink/src/internal.rs:398:13
|
36 | use self::iter::IntoValues;
| ---------------------- the item `IntoValues` is already imported here
...
398 | use internal::iter::IntoValues;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
so we fix this here.
Other imports were fixed as well.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
I'm not sure why the author added this in the first place, but I bet we
don't need this.
So remove code we do not need. Feel free to prove me wrong and revert
this patch.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
We iterate over full pathes to store entries here, which causes
`StoreId::new()` to error. But if we use the internal parsing helper
`StoreIdWithBase::from_full_path()` and then call `::into_storeid()` on
the resulting object, everything is fine.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This way we can get trace-level information about the logger itself when
it is generated. Because from time to time we might want to have a look
at that.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Finally merging the redefine of the StoreId implementation, which allows
easier handling of StoreId objects.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is a more complicated functionality (implementation-wise) of the
`Entries` iterator, which allows a callee to transform it into a
`StoreIdIterator`.
It uses the crate internal `PathIterator` type and a function to extract
the internals of that iterator which is then turned into an iterator
over `Result<StoreId>`, which can be used to build a `StoreIdIterator`.
The implementation is ugly, but we need to be able to transform a
`Entries` iterator into a `StoreIdIterator` in the
`libimagentryannotation`, and possibly in more cases where we want to be
agnostic over iterators.
Maybe there is a cleaner solution to this, hence the comment about
whether this should be removed.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this change applied, libimagstore does not export backend
representing types anymore.
This change is necessar because when we want to switch the `StoreId`
implementation from "complex and stateful" to "Stateless and Cow<'_,
&str>", we need to be able to have a type which represents a "`StoreId`
plus the path of the Store itself".
This "the path of the Store itself" is passed around as reference, to
minimize runtime impact.
Because such a type should not be exported by the libimagstore crate, we
make it `pub(crate)` internally. But because the backend APIs also have
to use this type, we would export the (private) type in the APIs of the
backend.
Because of that we make the backend API also non-visible to crate users,
which also decreases the surface of the libimagstore API itself.
Besides:
Remove function `Link::with_base()` which is not needed anymore (was
used in tests only).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This changes the implementation of the StoreId type to be less complex.
Before we always had to re-attach the path of the store itself each time
a StoreId object was passed to the store. Now we do not do this anymore,
hopefully we can move to a implementation of the Store API which takes
references of StoreId objects in the future.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
When printing the error chain, we print the error and then iterate over
the causes. Hence, we have to increase the printed number by one here,
because 0 (zero) is already printed.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch fixes a bug where the following code (here pseudocode) did
the wrong thing:
store.entries().in_collection("foo").for_each(||...)
because the `.in_collection()` call for the underlying PathIterator
object did not actually re-build the iterator. It only changed the
contained `PathIterBuilder`, but did not call `.build_iter()` on it to
rebuild the iterator object.
The test added with this patch checks whether the iterator does the
right thing.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch removes the magic constant we used when calling
`trace_unwrap_exit()` or `map_err_trace_exit_unwrap()`.
We used to call it with `1` as parameter, where the number was the exit
code to use. Now the implementation of the function does it
automatically (using 1 (one) as exit code).
All calls of these functions were fixed. Thanks to vim this was easy.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
We should be able, from the signature of the `generate_variants()`
helper function, to pass a `Vec<&T>` here, so cloning should not be
necessary.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Because this API only errors when write!() errors occur, we can return
the exit code as an error here.
This way the user of the API can immediately exit if there was an IO
error, but the API automatically takes care of the right return value,
returning (exiting) with zero (0) if there was an "Broken pipe" error
and with one (1) otherwise, which is the expected behaviour here.
All calls to that API were changed accordingly.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This removes the feature to be able to override log destinations from
the commandline.
This feature is removed because the --override-config feature from the
runtime already contains this functionality. It is a little more complex
to use, though this is a feature hardly used at all, so I rather go for
less code (less complexity) here than feature bloat.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This feature gives the users of the Runtime API the possibility to check
whether the user wants the ID reporting to be ignored as well (and more
important) to override the default behaviour where the runtime assumes
that if STDOUT is a pipe, it is a pipe to an imag command.
Before, this would not have been possible:
imag contact find Jonas --json | jq 'map(.fullname)'
because the runtime automatically prints the output of the command to
stderr and the touched IDs to stdout.
But now with this change, a user can override this default behaviour and
do:
imag contact --ignore-ids find Jonas --json | jq 'map(.fullname)'
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this patch, IDs can be fetched from the CLI via libimagrt. This
gives us the possibility to automatically handle "stdin provides IDs" in
libimagrt with less boilerplate in the binaries codebases.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch adds the id reporting feature to libimagrt::runtime::Runtime,
where processed ("touched") ids can be reported to the Runtime and then
get printed to stdout if stdout is a pipe.
Other output is automatically redirected to stderr if stdout is a pipe
now.
The function already returns `Result<_>`, the only thing that had to be
done was refactoring the code for actually returning an error in that
case.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this patch, the log level aggregation is abstracted away by using
zero sized types and a macro to implement the whole thing.
This does not alter functionality, but makes the code more readable.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
::stf::fs::create_dir_all() takes any ref to `Path`, which is what we
have here, so we can leave out the allocation of a new PathBuf object
here.
Also remove the match by a `if let Some(_)`, which increases the
readability a bit.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
With this change, the cache is tested before accessing the filesystem,
which probably increases the speed if the cache has the entry, because
we avoid the slow IO operation.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Matthias Beyer