What's coming up in imag (7)
Welcome to the 7th post about the last 14 days in imag, the personal information management suite for the commandline written in rust.
We had 22 merges in the last 14 days, 24 in the last 15 days, since the last article of the series.
Lets see what happened.
Merged pull requests
Next goes a short explanation on each of the merged pull requests from the last 14 days.
#339
The StoreId Type was rewritten and isn't a pub type StoreId = PathBuf
anymore. This change should be fully backwards compatible, so nothing will
change, though we have the possibility to implement custom traits on the type
from now on, which can make things easy in some situations.
#385
This merge fixed a typo in the Readme file. Thank you, Ron, for contributing to imag!
#349
The libimagstore got a Walk Type which can be used to walk whole store
directories. It is based on the walkdir crate and also iterates over
directories while recursing into them as well. So one can use this functionality
to explore the collections within a module storage.
#387
This merge removed some old code which did some configuration file checking but was wrong.
#389
This merge added an example configuration file to the repository.
#388
This was also a bugfix which fixed some missing error handling in the configuration file parsing code.
#390
This was a mass-update of the log crate dependency for all crates in the
repository.
#393
With this merge we updated the url dependency of libimagentrylink
#394
We made a helper function which could be used to filter links to external link files public with this merge.
#395
This was one of the greater PRs.
With this merge, we made the StoreIdIterator generic. Before this merge, the
StoreIdIterator type was a wrapper around the Paths Iterator type from the
glob crate. This wasn't really good, as we couldn't use the StoreIdIterator
type to iterate over a Vec<StoreId> for example. This merge makes this now
possible.
#384
llogiq made some improvements to the imag code base by running clippy on it and removing the warnings clippy yielded. Thank you very much for contributing to the imag codebase!
#401
General code cleanup in libimagutil.
#404
With these patches merged we now have the possibility to specify multiple tags
when using imag-tag to add or remove tags.
#402
General code cleanup in libimagrt.
#403
General code cleanup in libimagstore.
#412
We have now colored log output with libimagrt! Awesome!
#411
Some improvements to the CONTRIBUTING.md file.
#413
Error tracing prints the errors now in red (blinking). I really like that!
#410
A new library got into the imag codebase: libimagerror contains code to handle
imag error types.
#415
This is a follow-up patch for
#410
to move the trace_error() functions from libimagutil to libimagerror.
#417
This merge added a function in libimagrt to generate the Runtime setup or
exiting on failure. Just convenience and less boilerplate code in the binaries.
Yay!
#418
Here we added some helper functions in libimagentrytag for parsing the
commandline options.
#422
matthiasbeyer/libimagerror/generate-module
Another follow-up PR for
#410.
With this merged, we generate a full error module when using the macros from
libimagerror. This way, we have more flexibility in generating our error code.
#416
Aaaand another follow-up PR for
#410.
With this merged, we can call into_error() on all error kinds to generate the
appropriate error object out of them and into_error_with_cause(...) to pass a
cause. This will lead to more readable code everywhere.
Maybe another follow-up will follow which then removes the noisy
FooError::new(FooErrorKind::SomeErrorKind, Some(Box::new(other)))
and simply put
FooErrorKind::SomeErrorKind.into_error_with_cause(Box::new(other)),
which is way more readable IMHO.
What's coming up
I hope we can continue these libimagerror patches and add the ability to add
custom code in the error types. We need this for
#370 as we add some custom
members in the HookError Type in this PR.
I'm not really sure what else will be done in the next 14 days. I am still working on the diary implementation (actually with little to no progress in the last 14 days). Because of this I'm not sure what I can get done in the next 14 days.
I really hope to get some more tests merged. One PR (tests for imag-tag) is
already pending. I also want to get some markup-parsing library working (I have
a pending PR for this which is already three months old).
If you think you could contribute some code to imag, feel free to do so, there are a lot of open issues which are tagged easy!
tags: #linux #open source #programming #rust #software #tools #imag