anufrievroman/calcure: a terminal calendar built on plain text files and a man page

Three stores on disk, and none of them is a database file

The design decision that makes this different from most calendar software is where the data lives. The feature list says a plain text database in your folder for cloud sync, and the configuration section says the program creates a config.ini on first run at ~/.config/calcure/config.ini. Those are two separate locations, and a third mechanism sits alongside them: events and tasks from .ics files synced with clouds, shown in read-only mode, with the documentation carrying worked examples for Nextcloud and Google. So there is no server, no account, no daemon and no binary database file. There is a text file you can put in Dropbox, Syncthing, or a git repository, a configuration file, and a set of read-only subscriptions. The consequence is that syncing is not a feature you configure; it is whatever your operating system or file sync tool already does. The cost is equally concrete, and the feature list names it: private events and tasks are marked so they can be hidden. Masking in the display is not the same as keeping them out of the file, so if privacy means the data itself, this design does not deliver that. One detail suggests a considered migration path, since it can import events and tasks from calcurse, which is the other common terminal calendar.

pipx, an AUR package, NixOS, and then four steps on Windows

On Linux and Mac there are three documented routes, and the simplest is one command:

pipx install calcure

The README notes you may need pipx first, and that this gives the up-to-date version from PyPI. An Arch User Repository package is available through yay, and there is a NixOS package as well. Windows is a different document. The documented sequence is: install Windows Terminal from the Microsoft Store, install Python 3 from the Store as well, then install the program and its Windows-specific library by typing

pip install windows-curses calcure

and finally run it with

python -m calcure

Three things in that sequence are worth noticing. The Windows path uses pip rather than pipx, so the upgrade instruction of pipx upgrade calcure does not apply there. It installs windows-curses, which is a shim rather than something curses programs on Windows have by default, so this is a real dependency on that platform. And the run command is python -m calcure rather than plain calcure, which suggests the console script entry point is not on the path in a fresh Windows Terminal session. None of that is a criticism, it is curses on Windows, but it does mean the two platforms are not equivalent experiences and the README does not pretend otherwise. Upgrading on the pipx path is a single command, and after installing you may need to restart your terminal.

The package installs a man page, and reads its own version from code

The packaging metadata has a few choices worth reading. The build system requires setuptools 77.0.3 or later, the project needs Python 3.10 or higher, and the classifiers list 3.10 through 3.13. The dependencies are exactly two, holidays and icalendar, which the README describes as installing automatically. Then there is the entry point, declared as a console script:

[project.scripts]
calcure = "calcure.__main__:cli"

And there is a data-files table that installs a man page from the top level of the repository into share/man/man1. That is unusual for a Python package and it is a nice touch: after a pipx install, man calcure works, which for a terminal program is the documentation a user expects to have. The version is declared dynamic, resolved from an attribute on the main module, so the number in pyproject.toml does not exist and the source of truth is a line in the code. Two smaller signals. The repository holds a uv.lock, so the maintainer develops against a resolved lock file even though the published dependency list is two items. And the classifier says Development Status 4 - Beta, which does not match a project shipping releases numbered 3.4; either the classifier is stale or the project is comfortable describing itself as pre-release while shipping patch releases. Nothing depends on the answer, but it tells you which number to trust in an issue report.

Vim keys, a keybindings file, and a question mark in the app

The interaction model is a keyboard-first terminal program, and the feature list puts vim keys first. Beyond that there are two files that define the experience, and both are yours to edit. keybindings.ini customises the bindings, and config.ini holds colours, icons and other parameters, created on first run rather than shipped as a sample. The documentation has separate pages for the keys and for the settings, including a default config example. What makes this unusually well-organised for a small program is that the key list is reachable without leaving the program: pressing the question mark key shows the bindings, and the README says the same list is in the documentation. A tool that can answer what a key does while you are inside it removes a whole class of frustration, and it is a five-line feature that most tools of this size skip. The design goal stated in the feature list is operation with the fewest key presses possible, and combining that with the claim of minimal and customisable interface, the reading is a program with a small default surface and no modal wizard. The rest of the feature set follows from the same goal: a todo list with subtasks, deadlines and timers, icons chosen according to the event name, and a layout that resizes with the terminal.

Two dependencies explain most features, and one feature has no visible dependency

It is worth mapping the feature list onto the two declared dependencies, because the mapping is almost complete and the gap is informative. The icalendar library is the .ics support, which covers the read-only subscriptions and by extension the calendars you already pay for. The holidays library is the obvious source for the Persian calendar feature, since that needs a different calendar system rather than a different locale, and it also implies date and holiday awareness generally. So the holiday and calendar work is one library, and the standards-compliant calendar parsing is the other, and the dependency list is as small as it should be. The current weather feature is the exception. The feature list includes it, and neither declared dependency is a weather source, so the mechanism behind it is not visible in pyproject.toml. That does not mean it is undocumented; it means the manifest will not tell you, and a feature that reaches out to a network service from a terminal calendar is worth understanding before you run it, particularly since the program also syncs. It is the kind of gap to resolve in the source rather than in the metadata, and it is a reminder that a two-dependency manifest constrains how much a program can be doing behind the scenes.

Reminders are explicitly somebody else's project

There is a section of the README on setting daily reminders, and it does not describe a feature. It points to another project, calcxporte_r, written by a different person, and says you can try it to receive reminders of events in your Calcure. That is an honest gap rather than a bug, and it tells you the boundary of the tool. Calcure is a viewer and editor for local text files, and it does not run a background process, so it cannot notify you about anything while it is closed. The same boundary explains the .ics support being read-only: this is a consumer of external calendars, not a writer. Combined, those two facts define where calcure sits. It is a terminal front end over data you control, and it is not a synchronisation client, so if your requirement is that your phone sees what you typed, or that you get told about an appointment, you need something else in the chain. What the design does give you is that the other something can be anything: because the database is plain text in a folder, the sync and notification problems are solvable with tools that have nothing to do with this program. That is the same property that makes it portable, seen from the other side.

One maintainer, an irregular release rhythm, and MIT

The support section is unusually direct about the circumstances. It says the author is not a professional developer and works on open-source projects in free time, then lists a donation link and five cryptocurrency addresses. For a project like this that is a reasonable arrangement, and the licence is MIT, so nothing stands between you and reuse. The release rhythm is irregular in a way worth noting rather than worrying about. Version 3.2.1 came on 2025-04-23, then 3.3 on 2026-06-10, a gap of about thirteen months, and 3.4 on 2026-08-29, about eleven weeks later. Two of the three recent release titles are wordplay rather than change notes, one being a pun about crashes being fixed. The repository is not archived and the last push was on 2026-08-29, so the code is current with the newest release. For a program you run in a terminal to look at your own calendar, that profile is fine. What it means practically is that you should install the newest version rather than pin an old one, since fixes like the ones in 3.4 arrive when they arrive, and that the documentation in the linked GitBook is the place to look when a behaviour surprises you, since the README is deliberately a short index into it.

Editorial conclusion

Adopt calcure if you want a calendar that is files you own rather than a service you log into, because the storage model is the feature: a plain text database in a folder, a config.ini under your home directory, and read-only .ics subscriptions, which means your existing sync tool is the sync layer and nothing here needs a server. Do not adopt it expecting reminders or write-back, because the README sends you to a third-party project for daily reminders and the .ics support is read-only, so there is no path from this tool to a shared calendar. Two things to check first. On Windows, follow the four manual steps including pip install windows-curses calcure, because that is a different installation from the pipx, AUR and NixOS paths and it needs Windows Terminal. And note the version picture: 3.4 shipped on 2026-08-29 after a thirteen month gap since 3.2.1, the manifest still declares Beta, and the version string is read from the module at build time rather than pinned in pyproject.toml.

Frequently asked questions

Official sources

1. anufrievroman/calcure on GitHub
2. License: MIT
3. Project website
4. README
5. Releases