email rss
What's coming up in imag (42)
Apr 26, 2020
6 minutes read

This is the 42th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

This is it. 42. The magic number. It has been a long time since I last updated this blog. Unfortunately, development of imag has slowed down more than just a bit since I started working full-time about one year ago.

Still, a few things are happening right now, but mostly related to the infrastructure around imag. That is, the mailinglist is moved to sourcehut, as well as the repositories are. Also, the website will be moved to a new server soon.

But one thing after another.

Why we started moving the infrastructure.

Before all this, the infrastructure (the website, the git repositories and the malinglist) were hosted on uberspace on a centos6 machine. This was perfectly fine and worked really good. I am glad for their great service and if you need a small web space with a real linux/unix where you can actually ssh into and do things, definitively check them out! They also offer (installation or usage) of tools like mysql, mongo, redis, perl, php, ruby, erlang, go,… and so on. Check out the (german) wiki for more.

But, as centos6 support ends at the end of the year, I have to move the account. They offer a migration tool to their new centos7 infrastructure, so moving the website would be no big deal. But, as I would need to move the Domain of the website as well (they did offer domain registration way back when I started using their service for my private website), I started to do some research how and where to move my domain. imag-pim.org was always hosted with united-domains, but a friend suggested I move to Hetzner, which is less expensive and also has better service.

So I started moving the imag-pim.org domain to the Hetzner domain robot, which worked seamlessly. Now, I thought, I need to move the website and the mailinglist to the new uberspace host and point the DNS entries there. Easy, huh? But then, I thought, I could save a buck here and move the website to my already existing server, where I host some other stuff (for myself) as well.

So I started preparing for that.

But what about mailinglist? Also, what about git repositories? I could host them myself with gitolite and cgit, of course… but then what about CI? Also, hosting a mailinglist myself… I did not feel comfortable with that because I consider email mission-critical infrastructure and would like to leave that task for the professionals out there!

So I decided to…

Move to sourcehut

I already had a sourcehut (or sr.ht, that is) account before the whole thing, but now I am actively using it. I pushed all other imag-related repositories to sourcehut as well and added a CI configuration. It works really nice. I also added mailinglists for each project on sourcehut, and especially a “imag-dev” named mailinglist which might be accompanied by a imag-discuss mailinglist in the future (if at any point the amount of messages gets really high on imag-dev).

I also plan to pay for sourcehut as soon as the uberspace account is cancelled!

Moving the website

But what about the website itself? Also, git.imag-pim.org should live on, just to have one more backup of course!

So I moved the website and the git repositories to my new server, where I use nixos to configure the whole thing.

The website is served by nginx and the git repositories are located in a container which serves the gitolite repositories via cgit over lighttpd, which nginx (from the host) reverse-proxies for (is that a term?).

About imag itself

Well, that was a wall of text, wasn’t it? Now on to the topic why you (propably) came here for: imag itself.

I was surprised to see that 133 commits have landed on master since 2019-12-08, which was the last time I wrote an article on this blog! Only 32 of these commits are merges, though, which leaves 101 patches that landed directly on master, so they’re either trivial or changes that only took one commit to make.

The shortstat gives 427 files changed, 4697 insertions and 4364 deletions, which is a lot considering that I had not much time.

Some notable changes where:

  • 48943aa93 Removed the “collections” feature of imag-bookmark. The “collections” feature was useful to categorize bookmarks into collections, but a collection was mandatory for a bookmark. This changed because I think that tags are enough for categorization.
  • 3a6fb1b54, 750e5b25f, 61b0fe9fa, 8d737c503 and 247309bf4 were a number of PRs that changed the code of imag-diary, imag-log, imag-timetrack, imag-habit and imag-wiki to not call exit() anywhere in the code when an error occured, but rather propagate the error to the main() function and log it there and exit from this function with the appropriate error code.
  • 3e016d901 added a feature to imag-bookmark to open a bookmark in the browser.
  • 7ba3b2f2b changed the user interface for imag IO control. The flags -I and -O can now be used to tell imag how to behave on pipe input and output (see the help text of the respective option for what it does).
  • cb9f6e7f4 replaced the “failure” crate in the complete codebase with “anyhow”, for state-of-the-art error handling in Rust.

Of course, updates to dependencies and bugfixes were also applied, but I refrained from listing all this (probably boring) stuff here.

What about imag-mail?

I told you in the last issue of this series that I’m working on imag-mail and that imag-mail will be the big feature of imag-0.11.0.

And that has not changed!

I am still working on imag-mail and it still will be the main goal for the 0.11.0 release of the imag project.

In my tests, importing mails and listing mails (using notmuch as a backend for the actual data) works rather good by now. Listing mails is way slower than with notmuch. I hope to be able to improve that, though.

Right now, I am working on the interface and workflow for writing new mail or replying to existing mail as well as receiving and sending mail. That’ll be done with external scripts. imag itself will not receive or send mail, but you’ll get fine-granular control over scripts to do that, so you can stay with your offlineimap/mbsync/msmtp/fetchmail/sendmail setup!

imag will provide multiple pre- and post-hooks for both receiving and sending as well as control over parallel or sequencial sending, sendable/drafted/sent mailboxes.

I hope to be able to provide you a nice CLI email experience with imag 0.11.0!

For so long, I hope you’re all well in these hard times. Keep on hacking and stay healthy!


Back to posts