wtfutil's Go module path is still the old name, and the Homebrew tap is not

The rename has started in the tap and not in the module path

The first thing in this file is two warning banners, and they are the most important content in it. The project is being renamed and is moving to a new GitHub organisation, with the original repository URL given as the one you are reading and the new one given as github.com/linodians/tessera, described as the exact same repository with the history moving over. The second banner says the changes are in preparation for version 1.0 and include a rename from WTF to Tessera. You can already see the move half-finished in the install instructions, because the bleeding-edge Homebrew tap is under the new organisation while the main formula is still wtfutil. And the Go module path in go.mod is still the old one, which means an install by module path works today and stops working the day the path changes. Pin by version and expect a break.

The Homebrew formula lags, and the file admits it

The simplest install is two commands:

brew install wtfutil

wtfutil

What follows that block is the sentence that matters for anyone deploying this. The Homebrew version can sometimes lag a bit, because recipe updates take time to be accepted into homebrew-core. The alternative is a tap, and the file gives the command for it, which is under the new organisation's name. So there are two Homebrew routes with different freshness, and the one everybody copies from a blog post is the slower one. That is a small operational fact with an easy fix: decide which of the two you actually want, because a dashboard whose panels are stale is not a dashboard. The other install routes follow the same pattern, with a Go install line, a MacPorts route, a release binary you make executable yourself, a from-source path, and two Arch packages.

The documented source build sets GOSUMDB=off, and uses a superseded command

The from-source section is a sequence of environment variables and Go commands, and two of them deserve comment. The first is a line that disables the Go checksum database, which means the build path in this document does not verify module checksums. The second is a go get with an update flag, which is how you fetched and built a program before modules and is not the current way to install one, whose current form is a single line:

go install github.com/wtfutil/wtf@latest

Both of those instructions predate the toolchain the module now declares, and neither has been re-examined, which is a reasonable signal about how much of this file is maintained prose. If you are installing from source, use the Go install line and leave module verification on. If you are copying the block, you are copying a decision to skip checksum verification that was made for a different era and a different threat model, and that decision now belongs to you rather than to the file.

A module is a stanza in config.yml, which means a credential in a file

The module system is the whole design and it is worth stating plainly. Modules are described as the chunks of functionality that make the program useful, and they are added and configured by including their configuration values in your config.yml file, with a documentation page per module explaining what to put there. The suggested starting set covers DigitalOcean, GitHub, Google Calendar, HackerNews, Have I Been Pwned, NewRelic, OpsGenie, Security, Transmission and Trello, and the dependency list shows the wider surface, with clients for Docker, Spotify, Datadog, PagerDuty, Asana, Azure DevOps, Gerrit and the GitHub GraphQL API alongside an RSS reader and a weather service. So a deployment of this dashboard is a YAML file holding credentials for every service you enabled, which belongs in a secret store rather than in version control.

The maintenance paragraph is the most honest thing in the file

Under the heading about getting bugs fixed, the project says it is open-source software informally maintained by a small collection of volunteers who come and go at their leisure, and that there are absolutely no guarantees that, even if an issue is opened for them, bugs will be fixed or features added. It then suggests a practical remedy, which is creating a bounty to give someone an incentive to take the work on. Pair that with the fact that every module wraps a third-party API, and the shape of the dependency becomes clear. When a vendor changes an endpoint, the fix is unpaid work, and the project has told you in advance that it may not happen. If a module is load-bearing for you, the honest options are to fund it, to fork the module, or to not depend on it.

A terminal UI built on tview and tcell, and a Makefile with a typo

The rendering stack is in the dependency list, and it is a specific one. Terminal views come from tview with tcell underneath, tables from two separate table libraries, syntax highlighting from chroma, line editing from readline, flags parsed with go-flags, and numbers humanised by two different packages. The platform dependencies tell you the same story from the other side, with Windows support libraries for COM and pipes and a D-Bus client for Linux. Then the build file, which is where the age shows. It autodetects GOPATH by looking for bin, pkg and src directories, which was necessary before modules and is not now, and its list of phony targets contains isntall as well as install, a typo. Small things, and together they date the tree more precisely than the version number does.

Docs live in a second repository, and sponsors get a custom exit message

Two details at the end of the file show what kind of project this is. Documentation now lives in its own repository, and contributors are asked to make all documentation additions and updates there rather than in the code repository, which splits the two kinds of contribution cleanly and means a documentation pull request does not go through the code review queue. And then there is the exit message: the file links a page explaining how you can change the message the program shows when quitting, and it invites contributors and sponsors to set it to something of their own. That is a small piece of personality in a terminal program, offered to the people funding it, and it sits oddly next to a maintenance statement that guarantees nothing. Both are true, and together they are the honest shape of a volunteer project with a community.

Editorial conclusion

wtfutil fits a developer who wants a few panels of their own services in one terminal, and who is willing to own the configuration file. It does not fit a team that needs a maintained integration with a vendor API, because the file states that a small collection of volunteers maintains it with no guarantee that a bug will be fixed, and suggests a bounty as the remedy. Before you depend on a module, check its dependency path, because the package is mid-rename to Tessera and the module path in go.mod is still the old one, so a pinned install works today and a future path change breaks it. Then avoid the documented source build, which switches off the Go checksum database, and prefer the Homebrew tap or a release binary. And keep the configuration file out of version control, since enabling a module means putting a credential in it.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. wtfutil/wtf on GitHub