# What's coming up in imag (18)

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 18th 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.

# The past

I released filters in v0.1.1 and task-hookrs in v0.2.1.

They are now licensed under the terms of MPL-2.0, there were no changes in functionality besides, in the filters library, one can use a filter as an Fn now, but only on nightly rust. I did not bump the version from v0.1.0 to v0.2.0 because I do not think that nightly features should be promoted. They are nice to play with, but stable rust is my target, so I do not include these things as minor versions. And, as semver specifies, we are in v0.x.y, so I can do anything I want!

## New contributors

In the last 14 days I got some PRs:

• matthew-piziak submitted #797: “Simplify implementation of FoldResult and add tests”
• mario-kr submitted #810: “Single crate for all binaries”
• rnestler submitted #818: “[WIP] Use Result for from_storeid”
• Thiez submitted #820: “Add Iterator for Iterator> tracing”

Thank you all very much for your contributions!

## PRs merged/closed in the last 14 days

• 759 added support for commit-on-drop, so we create one commit for all changes of one imag run.
• 775 added readline support in libimaginteraction.
• 786
• 788
• 789
• 790
• 793
• 794
• 799
• 800
• 801 starts libimagannotation, a library for annotating entries (simply a combination of libimagnotes and libimagentrylink).
• 803 one part of 802
• 804 another part of 802
• 805
• 807 and another part of 802 which rewrites the external linking part of libimagentrylink.
• 808
• 809 a hook for the store which denies deletion of entries that have still links to other entries.
• 815 a prep-PR for the upcoming release.
• 816
• 817
• 819

## PRs opened in the last 14 days and not yet closed

There’s not much to say about the following list of PRs, so I just list them here.

## Issues opened and already closed

And there’s not that much to say about this issues either… so I simply list them here.

# The future

Well, the future. The release is really close. I am still not sure how to properly do the release.

As listed below, we have some discussion in #814, and TheNeikos suggested to simply run cargo publish --no-verify in a loop until all crates are up there. I do not like this idea very much, though I do not see an alternative. If you have an alternative, feel free to tell!

For readers that are not familiar with the imag codebase, here’s the problem again:

• We have multiple crates in one repository.
• We have multiple root crates in one repository.

That means, we have a rather complex net of dependencies of crates in one repository. We have more than 30 crates there. A release process would need to find the one crate that does not depend on any other crate from our repository, cargo publish that one and then walk up the dependency tree until all crates are published. For this, we would either need to parse the Cargo.toml files, to find the dependencies, or just loop over all crates and try to force-publish (as in cargo publish --no-verify) them.

If you have any idea how to do this in a clean and nice (and reproducible) and automated way (I do not want to do this by hand, really), feel free to post a comment on #814!

## Issues opened and not yet closed

Some issues were opened that are not yet closed.

• 791
• 792 wants ENV-var expansion from the configuration.
• 798 wants the git-mv hook for Store::move* functions
• 802 tracking issue for the libimagentrylink rewrite to return iterators instead of Vecs.
• 806
• 813
• 814 is a discussion how to do the upcoming (first) release (version 0.2.0)

That’s it for today, I guess.