What's coming up in imag (19)
Another 14 days vanished quickly as hell.
Read what happened in the imag codebase in the last 14 days, in this 19th iteration on whats coming up in imag, the text based personal information management suite for the commandline.
imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.
We have more than 150 stars now! Wow!
Besides that we had really not that much progress in the last 14 days. My masters degree keeps me busy all day long and I really have a hard time with all the things I have to do for my courses, so progress slows down way more than I expected. But I can't change that, so ...
PRs merged/closed in the last 14 days
- 821 imported commits from
v0.2.0release branch into the master branch.
- 822 updates our
dependencies. Luckily this worked without too much hassle. Still, we had
some problems while updating. We only had to update
a method from
itertoolswhich was removed. We also had to update
uuidand they really should depend on the same version of
uuid, so I updated
task-hookrsto the latest
uuid, which in fact included some code removal in the codebase of
task-hookrs. This was because
uuiddepends (and we also need it) on
serde, which was update from
0.8.*. As serde included some new awesome things, we were able to remove some code in
- 827 implements
StoreId, which is a really neat improvement in my opinion. We
derive()d it before, but we now only compare the
localpart of the
StoreIdobject (read: The store-part, not the path to the store itself, which could be absent sometimes, causing weird bugs).
Also, two really old PRs were closed. I do not list older PRs normally, but these two are really noteworthy:
- 624 included cargo
workspace support in our build setup. I'm not sure it works the way I
expected it to, as (for example)
clapgets rebuild several times... but at least cargo doesn't yell at us anymore, so I included it.
- 656 sets the codegen units
2. I hope we get slightly better build times on travis from that.
PRs opened in the last 14 days and not yet closed
- 826 bakes in shell
completion generation for all the
- 832 – now, this is a
really great PR from mario-kr. Mario found a
way to build shell completion for all the imag tools, starting at the
imagbinary itself. I did not even think about this as solution, but it works and I'm willing to merge this as soon as Mario did some cleanup work in the PR. What he did is: He
ui.rsfiles, where we (more or less by accident) always used the same function name to build the
build_ui(App) -> App. He includes these source files via a neat macro as sub modules and is then able to call all these
build_uifunctions to build a
Appobject (with subcommands for each imag module). From that
Appobject, he can retrieve the bash/fish/zsh completion (at build time). This is awesome!
Issues opened and already closed
As far as I see, we had no issues opened in the last 14 days that were also closed within theses two weeks.
Maybe in the next iteration again.
Lets have a quick look what the future might bring us in the imag codebase.
Issues opened and not yet closed
- 830 was our only issue
we opened in the last 14 days. It wants a rewrite of all the
*.shscripts we use to test binaries. These scripts really should be rewritten in Rust, we now have the ability to do tests in-memory, so there shouldn't be any issues with implementing these things in Rust. It is really a trivial task (not for a complete rust beginner IMO), so I'll not start implementing this soon, so others can step up.
As said above, I have a lot to do for my masters degree, so I cannot tell how much we can get done in the next two weeks. I'd love to see some progress with the email module, so we can merge this one at least, but I cannot promise it, sadly.
This does not mean I'm not interested in imag anymore. I'm interested even more in it. I just do not have enough time at the moment to do all the things I want to do.
tags: #linux #open source #programming #rust #software #tools #imag