Skip to main content

Farora

A local-first, plain-text task tracker with a Textual TUI.

Tasks live as Markdown files with YAML frontmatter in a plain folder, so they sync over any file-sync engine, diff cleanly in git, and stay readable without Farora.

Install

Use a recent uv — it provisions Python 3.14 for you:

uv self update             # or: brew upgrade uv
uvx farora                 # run without installing
uv tool install farora     # install persistently
If you see "requirements are unsatisfiable"

Older uv releases pick whatever interpreter they find first and give up when it is below 3.14:

Because the current Python version (3.12.9) does not satisfy Python>=3.14 and
farora==0.5.0 depends on Python>=3.14, we can conclude that farora==0.5.0
cannot be used.

Updating uv is the fix. If you cannot update it, name the interpreter explicitly:

uvx --python 3.14 farora
uv tool install --python 3.14 farora

Supported configuration

Farora 0.5 is developed and tested on macOS with Python 3.14+. uv provisions the interpreter for you.

These tools are optional — each unlocks a feature, and Farora degrades cleanly without it:

Tool Unlocks
helix e opens the task body in helix (otherwise $EDITOR, then vi)
mdcat ≥ 2.11 v / V live markdown render with inline images
WezTerm v renders side by side in a split pane
git ≥ 2.30 Sync a task repo across machines

Linux and Windows are not supported in this release.

Commands

Command Purpose
farora launch the TUI
farora doctor validate and reconcile a repo
farora gc [--older-than DURATION] purge expired tombstones now

All commands accept --repo PATH, defaulting to $FARORA_REPO, else ~/.farora.

Deleted tasks are kept before they are gone

Deleting a task removes its tasks/FAR-42.md, but its journal stays behind as a tombstone holding a full snapshot of the task — frontmatter and body text. That is what u undoes a delete from, and what a future farora restore would rebuild from.

So a deleted task's text is still readable in the repo, in projects/FAR/journal/FAR-42.jsonl, until garbage collection removes it. If a task held something sensitive, deleting it is not the same as shredding it — anything syncing or backing up the folder has the snapshot too.

Garbage collection runs opportunistically: every ordinary farora run sweeps the repo it opens, so there is no daemon and nothing to schedule. Tombstones older than the retention window are purged; everything else — every live task, and every tombstone still inside the window — is left alone.

farora gc                      # purge now, using the configured window
farora gc --older-than 0s      # purge every tombstone, right now
farora gc --older-than 7d      # ... or everything deleted over a week ago

Configure it in ~/.config/farora/config.toml:

[gc]
enabled   = true    # false: never sweep on ordinary runs (`farora gc` still works)
retention = "30d"   # how long a deleted task's snapshot is kept: s | m | h | d | w

Both keys are optional and the values above are the defaults. Purging is permanent: once a tombstone is collected, undo and restore have nothing to work from, and the task number is never reused.

License

Proprietary. See LICENSE.

Free to use for any purpose, including commercially — by individuals and by companies, at no charge and without asking. Redistribution and modification are not permitted.

To license Farora on other terms, contact hi@farora.tools.

Release files for farora 0.5.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distribution (wheel)

Table of built distributions (wheels) for farora 0.5.1
File Interpreter ABI Platform
farora-0.5.1-py3-none-any.whl Python 3 none any Details

Release files / farora-0.5.1-py3-none-any.whl

Download URL farora-0.5.1-py3-none-any.whl
Size 303.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
85499572c964234d1001ba07b489ac867e8eedba493df75f6fbc5d775748b152
BLAKE2b-256 checksum
How to use checksums
5a8d364da7dfaecc07de56e80ad5d466fde8025690818027f978a1b2eb56032a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 11, 2026.

Transparency log

Release history Release notifications | RSS feed

0.5.4

1 release file

0.5.3

1 release file

0.5.2

1 release file

This release

0.5.1 This release

1 release file

0.5.0

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page