Veirt/weathr: a terminal weather app with ASCII animations

What weathr actually solves in a terminal session

Most terminal weather tools answer a data question: temperature, wind, precipitation probability, tomorrow. weathr answers a different one. It turns the current condition into a moving scene drawn in ASCII, so the weather is something you glance at rather than something you query. The README describes it as "a terminal weather app with ASCII animations driven by real-time weather data", and the feature list is animation-first: rain, snow, thunderstorms, flying airplanes, day/night cycles.

The audience follows from that. Someone who lives in a terminal all day and wants a small animated panel in a spare pane is the target. Someone who needs to plan a week of outdoor work is not. The README documents no multi-day forecast view, no radar, and no alerting, so the tool is deliberately narrower than a weather dashboard. It also supports simulation flags, which says something about intent: the animations are the product, and the weather data is what drives them.

How the animation pipeline runs: Open-Meteo in, crossterm out

The dependency list in Cargo.toml tells most of the story. reqwest with the json feature handles HTTP, tokio runs the async runtime, serde and serde_json parse responses, toml reads the config, and crossterm drives the terminal. There is no rendering framework and no game engine; the animation is crossterm drawing characters on a timer, with rand supplying variation so the scene does not loop identically.

Weather data comes from Open-Meteo, per the README. Location comes from one of two paths: coordinates you set in the config, or IP-based detection. When auto-location is active, the README states the app requests ipinfo.io to estimate your location. City names are then resolved through reverse geocoding against Nominatim and OpenStreetMap. That is a three-hop chain (IP lookup, weather fetch, reverse geocode), and the README's own table shows the failure mode: when no city matches, every display mode falls back to raw coordinates. A build with no network reaches none of these hops, and the README documents no offline or cached mode.

The config schema is small and flat. Under [location] you get latitude, longitude, auto, hide, display, and optional city and city_name_language overrides. Under [units] you pick temperature, wind_speed and precipitation. Two top-level booleans, hide_hud and silent, control how much text sits around the animation. There is a documented shortcut for the geocoding hop: setting city manually skips reverse geocoding entirely, which also removes one network request.

Installing weathr and running a first simulated scene

The README lists several install paths. The quickest on macOS, Linux and FreeBSD is the install script, which downloads the latest binary:

curl -fsSL https://raw.githubusercontent.com/Veirt/weathr/main/install.sh | sh

If you prefer your package manager to own the binary, Cargo works, and the crate is published as weathr:

cargo install weathr

Homebrew, MacPorts, AUR (weathr and weathr-bin), Winget (Veirt.weathr) and a Nix flake are also documented. There is a published container image, and the README notes you should run it interactively so the TUI can reach your terminal:

docker run --rm -it ghcr.io/veirt/weathr:latest

Before a real run, create the config directory. On Linux that is ~/.config/weathr, and the file is config.toml:

mkdir -p ~/.config/weathr

A minimal config that pins a location and skips IP detection looks like this, with keys taken from the README's example:

[location]
latitude = 52.5200
longitude = 13.4050
auto = false
display = "mixed"

[units]
temperature = "celsius"
wind_speed = "kmh"
precipitation = "mm"

The fastest way to see what the app does without depending on the network is the simulation mode. The README gives these examples:

weathr --simulate rain
weathr --simulate snow --night
weathr --simulate clear --leaves

You should see the animated scene for the named condition, with the HUD showing weather details unless you pass --hide-hud. Press q or Q to quit, or Ctrl+C. The README also documents NO_COLOR, COLORTERM and TERM as respected environment variables, so NO_COLOR=1 weathr gives a monochrome run.

Where weathr stops being the right tool

The limitation is scope, and it is visible in the README rather than hidden. There is no forecast horizon. The README's usage section covers a live run, simulation flags, unit overrides, location flags and keyboard controls; nothing describes tomorrow, a ten-day view, or historical data. If you want to know whether to move a meeting, weathr will not tell you.

Network dependency is the second constraint. Open-Meteo supplies the weather, ipinfo.io supplies auto-location, and Nominatim supplies city names. The README does not document a cache, an offline mode, or a fallback provider, so a machine behind a restrictive proxy gets no scene. Reverse geocoding is explicitly best-effort: the README's table states that when a city cannot be resolved, including at open sea, all display modes fall back to coordinates. That is graceful, but it means the city label is not guaranteed.

Finally, the output format is the point and also the ceiling. ASCII animation needs a terminal that crossterm can address and enough space to draw in. Piping weathr into a log or a CI job loses the only thing it does well. The Dockerfile is instructive here: it builds to a scratch image with ca-certificates and zoneinfo copied in, which confirms the app expects to talk to the network at runtime and has no bundled data.

weathr versus a plain text weather client

The obvious alternative is a conventional CLI client that prints a table, such as the many wttr.in-style tools and terminal weather scripts. The difference is not data quality; both can pull from public forecast APIs. The difference is what the terminal is doing. A text client writes a result and exits, so it composes with grep, scripts and status bars. weathr runs a TUI loop with an animation clock, so it owns the terminal while it is open.

That trade-off is real in both directions. A text client can be scheduled, diffed and parsed; weathr cannot, and the README does not offer a non-interactive output mode. In exchange, weathr gives you something a table cannot: a glanceable scene that changes with the condition, plus day/night cycles and simulation flags for previewing conditions you are not currently in. If you want weather data inside a script, the plain client is correct. If you want a small animated pane, weathr is the one designed for that.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-12. The most recent tagged release in the list is v1.4.0 from 2026-02-23, with v1.3.0 and v1.2.3 before it in February 2026. Cargo.toml declares version 1.4.0, edition 2024, and a rust-version floor of 1.85.0, so building from source needs a reasonably current toolchain. The Dockerfile pins RUST_VERSION to 1.94 and DEBIAN_RELEASE to trixie, which is a separate, newer floor than the crate manifest states.

Upgrade cost is low for users and moderate for packagers. The config surface is a handful of keys, and the README documents CLI flags that override config values, so a config file does not need rewriting to change units or location for one run. Packagers carry more: the AUR entries, Homebrew formula, MacPorts port, Winget manifest, Nix flake and GHCR image all need to track releases, and the flake also exposes a home-manager module with a programs.weathr.settings option, which means the Nix surface is larger than the others.

Licensing is GPL-3.0-or-later per Cargo.toml, matching the GPL-3.0 licence file. For an end user running the binary, that is unremarkable. For anyone embedding weathr's code in another product, the copyleft terms apply, and the Dockerfile's scratch image is a distribution of the binary. This is a factual note about the declared licence, not legal advice; check the LICENSE file and your own obligations.

Editorial conclusion

Adopt weathr if you want weather as ambient terminal decoration and you accept the Open-Meteo dependency and the ipinfo.io call that auto-location makes. Do not adopt it as a forecast tool: the README documents no multi-day outlook, no radar and no alerting. Before installing, check the config path for your platform and decide whether you want auto = true, because that setting is what sends a request to ipinfo.io.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Veirt/weathr on GitHub