Skip to main content

Install

How to get overpower, the op shortcut that is deliberately not installed, and the flag that proves the package arrived whole.

There is nothing to install, in the usual sense, to try overpower once. Pick the manager you already use.

Getting it

uvx overpower@latest install --skill panlabs-python-standards --runtime claude-code

uvx downloads the package into an isolated, ephemeral environment, runs it, and throws the environment away. Nothing is left on the machine except whatever overpower itself wrote: no global site-packages entry, no leftover virtualenv, nothing to uninstall later because you tried a flag once. This is the right way to run overpower from CI, from a one-off terminal, or from any context where installed forever is the wrong default.

If you reach for overpower often enough that typing uvx overpower@latest every time is friction, install it as a persistent tool. That puts an overpower executable on your PATH, resolved once instead of on every invocation, which means it no longer self-updates the way @latest does, and uv tool upgrade becomes something you run on purpose.

What it needs from the machine

Python 3.12 or newer. That is the floor the package declares, and uvx respects it on its own: it builds the environment with an interpreter that qualifies, downloading one if the machine has none that does.

The dependencies ship with the package and you install nothing by hand. There are four, all of them terminal work: the command-line parser, the screen painter, the engine behind the wizard's questions, and the keyboard layer under it.

The catalog is not one of them. It is embedded in the package itself, which is why the version of the tool is the version of the catalog.

The op shortcut you have to make yourself

Typing overpower in full, every time, is longer than most people want. The obvious fix is a shell alias:

alias op='overpower'

overpower does not create this alias for you, and does not ship an op executable. That is a deliberate omission, not an oversight. op is already the name of the 1Password CLI, which lives at /usr/local/bin/op on a great many developer machines and typically sits ahead of ~/.local/bin on PATH. Shipping a second op would silently shadow a credential tool, and uv will refuse the entire installation the moment it detects a name collision among tools it manages, so even the honest failure mode costs you the overpower command too.

If you already use 1Password's op, pick a name that does not collide. Only you know what occupies that name on your machine, which is why the decision is left to you, as a line you type once, rather than baked into what the package installs.

alias opw='uvx overpower@latest'

An alias is a convenience of an interactive shell and nothing more. It does not expand under sh -c, which is how a Makefile target and many CI runners invoke a command, so op inside one of those contexts fails with command not found regardless of what your shell profile defines. That costs nothing in practice, because the line a Makefile, a CI workflow, or this site itself actually writes is the full uvx overpower@latest anyway.

--version as proof the package arrived whole

uvx overpower@latest --version

--version reads the version from the package's own installed metadata, not from a string hardcoded somewhere in the source. Since the catalog is embedded in the same wheel as the code, the version number it prints is also, by construction, the version of the catalog that came with it.

It is the cheapest available check that what landed on the machine is what was supposed to land: no partial install, no stale cache masquerading as current, no ambiguity about which catalog you are about to install from.