Eight weather backends, four frontends, and a config file that only exists after wego fails once

The first run has to fail before the config file exists

Setup begins with a deliberate error. Step zero of the documented flow is to run `wego` once, and what you get back is not a forecast but an error message plus a generated config file at `$XDG_CONFIG_HOME/wego/wegorc`, or wherever `os.UserConfigDir()` points on your platform, `~/.config/wego/wegorc` on Linux. Only after that do you choose a backend and run it again. Resolution order is fixed: `$WEGORC` takes precedence outright, then the XDG path if it exists, then `$HOME/.wegorc`, kept as a legacy location for backward compatibility, and only when none of the three exist is a fresh file written to the XDG path. The consequence for automation is real: the first invocation exits with an error by design, so a cron entry or status bar wired up early will show a failure until the file exists. The quieter consequence is the legacy path. A `.wegorc` left in your home directory by an older install is still honoured whenever the XDG file is missing, so preference edits can land in a file you are not reading.

The dependency list asks for Go 1.20 while go.mod declares 1.27

The toolchain requirement is stated twice and the two numbers do not match. The dependency section asks for a working Go 1.20 environment, while the module file declares `go 1.27` beneath `module github.com/schachmat/wego`. Provisioning from the prose on a 1.20 toolchain ends in a version error at build time, and the prose never says how new your toolchain has to be. The install command itself is one line, which makes the mismatch easy to miss:

go install github.com/schachmat/wego@latest

This is also the only install path spelled out anywhere in the repository. Everything else is delegated: the installation section tells you to check your distribution for packaging, with a repology link for versions, and falls back to `go install` for dropping the binary into your `$GOPATH`. If your platform does package it, that route gives you a version the package manager picked rather than `@latest`, and the repository says nothing about how the two differ.

Two backends need no key, and one of them only covers Sweden

`open-meteo` and `smhi` are the only backends described as free with no API key required, and each takes two lines of config:

backend=openmeteo
location=New York

backend=smhi
location=59.33,18.07

SMHI is scoped to Sweden and surrounding areas, so keyless operation is not global. Every other network backend wants a credential before wego prints anything, and each names it differently: `owm-api-key` for Openweathermap, `weather-api-key` for WeatherAPI, `caiyun-api-key` for Caiyun, `wwo-api-key` for Worldweatheronline, `pirateweather-api-key` for Pirateweather. One carries its own catch. Worldweatheronline no longer offers free API keys, which the repository tracks as issue 83. Switching to a keyless backend is therefore the quickest way to see output at all, and also the quickest way to leave an obsolete key sitting in a file you keep editing.

The location field changes format from one backend to the next

There is no single location format. Open-meteo, Openweathermap and WeatherAPI all show `location=New York`, a city name. SMHI shows `location=59.33,18.07` and Caiyun shows `location=121.47,31.23`, both coordinate pairs. Pirateweather requires a latitude and longitude and gives `location=40.71,-74.01`, and its backend name in the config file is `pirateweather.net`, not `pirateweather`. The json backend takes neither: it reads a local file.

backend=json
location=/path/to/weather.json

That backend is described as useful for testing or offline use, which makes it the one that works with no network at all. Apart from Pirateweather, which the README says requires a lat,lon location, nothing states which backends accept which of the two formats. The README does not document the JSON schema that file has to follow either, so an offline setup means reading the backend source to learn the field names.

Only the json frontend is meant for a machine, and colour is on by default

Output is chosen with the `--frontend` flag or with `frontend=…` in `.wegorc`, and the example given is `wego --frontend emoji London`. The four choices are `ascii-art-table`, the default and a classic colored ASCII art table, `emoji` for a compact emoji display, `markdown` for a table, and `json` for output suitable for piping to other tools. Only that last one is machine readable, so any script has to select it explicitly, and two of the other three assume more than a reader: the dependency section requires a utf-8 terminal with 256 colors for `ascii-art-table` and `emoji`, plus a monospaced font containing all the required runes, with `dejavu sans mono` given as the example. Those same two frontends render temperatures and wind speeds in colour out of the box, and three documented switches reverse it: the `--monochrome` flag, `monochrome=true` in the config file, or the `NO_COLOR` environment variable.

NO_COLOR=1 wego

Any capture of wego output into a file, a log or a script inherits colour codes unless one of those is applied, and the config file route is permanent, so a setting added once while debugging keeps suppressing colour for every later run. Nothing says which of the three wins when more than one is set, nor whether the markdown and json frontends are affected at all.

Disk caching is on with a TTL, and the cache itself is undocumented

Weather data is cached on disk with a configurable time to live, set through `--cache-ttl`. Alongside it sit the preferences you are told to adjust after the first successful run: `days`, which caps the forecast at 1 to 7 days, `units`, which takes `metric`, `imperial`, `si` or `metric-ms`, and the per-language `…-lang` keys that back the multi language support. What none of this section tells you is where the cache lives, what it is keyed on, or what happens when a lookup hits. That matters when you are on a metered key: a cached forecast and a live request look identical in the terminal, so you cannot tell from the output whether a call was billed. It also means a TTL experiment is the only way to find out whether changing `units` or `days` invalidates what is already on disk, since the README gives no rule either way.

ingo arrives as a 2017 snapshot while the rest of go.mod is tagged

The module file lists five direct dependencies. Four carry ordinary version numbers: `github.com/mattn/go-colorable v0.1.15`, `github.com/mattn/go-runewidth v0.0.30`, `github.com/muesli/mango v0.2.0` and `github.com/muesli/roff v0.1.0`, with three indirect entries for `clipperhouse/uax29/v2 v2.2.0`, `mattn/go-isatty v0.0.20` and `golang.org/x/sys v0.29.0`. The fifth direct dependency is the odd one: `github.com/schachmat/ingo v0.0.0-20170403011506-a4bdc0729a3f`, a pseudo-version whose timestamp is 2017-04-03, and it is the project named in the feature list as handling automatic config management. So the config file that `wego` generates rests on a dependency pinned to a 2017 commit, while the other direct dependencies carry tagged versions. That is a deliberate-looking split rather than an accident, but nothing in the repository explains it, and it means config keys you see in the README are validated by a 2017 parser.

Release 2.4 is five months older than the last commit

Three releases are visible: 2.4 on 2026-04-11, 2.3 on 2024-08-25 and 2.2 on 2023-06-04. The repository is not archived and its last push is dated 2026-11-01, more than six months after 2.4 and well after the twenty month gap that separated 2.3 from 2.4. Because `go install github.com/schachmat/wego@latest` follows the default branch rather than a tag, the binary you end up running is whatever that branch holds, which is not necessarily 2.4. There is no changelog file at the top level to arbitrate: the entries are `.github/`, `.gitignore`, `CONTRIBUTING.md`, `LICENSE`, `README.md`, `backends/`, `frontends/`, `go.mod`, `go.sum`, `iface/` and `main.go`. If you need to state which code you are running, the tag list is the record, and the distance between a tag and the branch tip is yours to audit rather than the repository's.

Editorial conclusion

wego suits people who already live in a terminal and want a readable forecast from a keyless provider. Go for it if open-meteo or SMHI covers where you are, and read the config file it writes before you automate it. Do not go for it if you need a documented API contract, a changelog between tags, or a config library newer than a 2017 commit: the ingo pin and the gap between release 2.4 and master are both yours to audit first.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. README
4. Releases
5. schachmat/wego on GitHub