wee-slack ships one WeeChat script under two names, and declares 3.0.0 with no matching tag

One script, two file names, and a build directory that is not in the repository

The script has one implementation and two names, and the pages disagree about which is which. Installing from inside WeeChat runs `/script install slack.py`. Installing by hand downloads `wee_slack.py`, drops it in the `python/` directory of the WeeChat data files, and symlinks it from `autoload`:

mkdir -p ~/.local/share/weechat/python/autoload
cd ~/.local/share/weechat/python
curl -O https://raw.githubusercontent.com/wee-slack/wee-slack/master/wee_slack.py
ln -s ../wee_slack.py autoload

Reloading it later takes `/script load wee_slack.py`. The Dockerfile takes the third spelling, copying `build/slack.py` into `/home/user/.local/share/weechat/python/autoload/slack.py`, and its own usage comment warns that you need `slack.py` sitting in `~/.local/share/weechat/python` outside the container for saved state. The top level of the repository holds `build.sh` but no `build` directory, so that COPY step only works after the local build script has assembled the single file. Anyone scripting the install has to guess which of the three names is on disk.

pyproject declares 3.0.0 while the newest tag is v2.11.0

The project table in pyproject.toml reads `version = "3.0.0"`. No 3.x tag exists. The releases on file are v2.10.2 from 2024-02-18, a nightly dated 2024-02-20 and v2.11.0 from 2024-10-09, so the newest artifact anyone can install predates the declared version by about two major numbers. The nightly entry sitting between the two tagged releases is itself odd: it is older than v2.11.0 by seven months, which means the nightly line and the tag line were not produced on the same schedule. Commits have continued since, with the last push on 2026-08-17, so the gap is not an abandoned repository. A `CHANGELOG.md` sits at the top level next to all of this. Whether the unreleased commits constitute 3.0.0 is not something the release list settles.

pylint is configured in detail but never declared as a dependency

pyproject.toml carries a full pylint configuration: `[tool.pylint.main]` with `ignored-modules = ["weechat"]`, and a messages control block switching off nine checks from `dangerous-default-value` to `too-many-instance-attributes`, each with a reason. The dev dependency group lists pyright, pytest, pytest-cov, ruff and typing-extensions. Pylint is not among them. Ruff is, and there is a `.flake8` file at the top level too, so three linters are configured and one is installed. The ruff exclude list names `wee_slack.py` and `_pytest/*`, and `_pytest` is not one of the repository's top level entries, which are `.flake8`, `.github/`, `.gitignore`, CHANGELOG.md, Dockerfile, LICENSE, README.md, build.sh, docs/, `extract_token_from_browser.py`, `generate_types_from_mocks.py`, `generate_weemoji.py`, main.py, mock_data/, pyproject.toml, scripts/, slack/, tests/, typings/, uv.lock and weemoji.json.

An OAuth token costs four features, a session token cannot be revoked

The setup section is unusually honest about the token choice. Registering an OAuth token starts with a single command run inside WeeChat:

/slack register

The page then lists what OAuth costs you: if the team restricts app installations an admin has to approve wee-slack, a free team spends one of ten app slots, the subscribe and unsubscribe commands do not work, and threads can only be marked read locally, so they go unread again after you reload the script. Session tokens avoid those four costs and carry their own warnings instead: they cannot be revoked, they are not officially supported, and they may stop working at any time. The repository ships `extract_token_from_browser.py` at the top level with an optional `extract-token` group pulling cramjam, plyvel, pycryptodome and secretstorage, none of which load unless you ask for them. The single runtime dependency is websocket-client 1.8.0 or newer. Multiple teams need no extra setup: the feature list says to add several API tokens separated by commas.

The FreeBSD line installs a Python 3.6 package for a project that asks for 3.8

Dependencies have a one line installer per distribution, and one of them contradicts the project metadata. `requires-python` is `>=3.8` and pyright is pinned to `pythonVersion = "3.8"`, yet the FreeBSD instruction is `pkg install py36-websocket-client`. The other five are current: Arch uses `pacman -S python-websocket-client`, Debian and Ubuntu use `apt install weechat-python python3-websocket`, Fedora uses `dnf install python3-websocket-client`, OpenBSD uses `pkg_add weechat-python py3-websocket-client`, and anything else is `python3 -m pip install websocket-client`. WeeChat 2.2 is the stated floor, with a note that Python 3 modules became required in WeeChat 2.6. The container image takes the Alpine route:

FROM alpine:latest

RUN apk add --no-cache \
	ca-certificates \
	python3 \
	py3-websocket-client \
	py-pip \
	weechat \
	weechat-perl \
	weechat-python

That list installs weechat-perl and weechat-python, while the repository holds Python only.

Project metadata names a package but declares no build system

The `[project]` table gives a name, a version, a license, an author, a readme, a Python floor and one dependency, and `[project.urls]` points Homepage and Repository back at the same GitHub URL the repository already lives at. There is no `[build-system]` table, no package discovery configuration and no console script entry point, and the `description` field is an empty string. None of that blocks installation, because the documented install path never builds a package: you either let WeeChat fetch `slack.py` or you curl one file into a data directory. It does mean there is nothing here to `pip install`. A `main.py` sits at the top level next to the `slack/` package, and `pyright` runs in strict mode over `extract_token_from_browser.py`, main.py, slack, tests and typings, with `reportMissingModuleSource = false` because the WeeChat module is a stub. Those stubs are what `generate_types_from_mocks.py` produces out of `mock_data/` into `typings/`, and ruff is told to skip `typings/weechat.pyi`.

The setup walkthrough stops inside the OAuth step

The table of contents promises a long tail: Commands and options, Threads, Emoji characters and tab completions of emoji names, Cursor and mouse mode, Removing a team, Optional settings, an FAQ covering buffer sorting, group by team, system wide notifications and multi line messages, plus Known issues, Debugging and Support. None of those sections appear in the document. The text that is present stops in the middle of the OAuth walkthrough, at the sentence explaining what to do when the authorization page shows a different team than the one you want to add, which ends at 'you can change the team i'. That leaves the entire settings surface, every command, every option and the whole Known issues section undescribed here, which is why the settings a team would want to change, and which of them reach Slack, cannot be answered from this page. What the feature list does state stays concrete: edited messages append (edited) and change in place, unfurled URLs replace the original message instead of adding one, and regex editing accepts s/oldtext/newtext/.

The faster redraw claim arrives without a number to check it against

One feature bullet promises a smarter redraw of dynamic buffer info with much lower CPU percent. No measurement accompanies it, and the rest of the list is written the same way, as behaviour rather than as numbers. Threads work, Slack status is supported, slash commands including custom ones pass through, uploads work, emoji reactions work, and history is replayed at startup with the read marker set to the correct position in it. Read markers sync both ways so the web client does not re-read messages you have already seen, open channels stay in step with Slack across your other clients, typing notifications appear globally for direct messages, and away and back status are handled. The unread behaviour after a reload, named in the token section as a consequence of local only thread reads, is the one claim here with a stated consequence attached to it. The CPU figure is the only performance claim, and it has nothing behind it.

Editorial conclusion

wee-slack is worth reading if you already run WeeChat and want Slack features the terminal client does not ship, because every mechanism it adds, threads, reactions, typing notices, read marker sync, is implemented against the Slack API rather than by scraping. It is a poor fit for anyone who wants a supported package, since the newest tag is v2.11.0 from 2024-10-09 while the project file claims 3.0.0, and commits have landed as recently as 2026-08-17 without a release. Before you install, decide which token type you are willing to live with: an OAuth token costs you four features, and a session token cannot be revoked. Copy the script rather than packaging it, since nothing in pyproject declares a build backend or an entry point. And read the two install paths together, because the file is called slack.py in one and wee_slack.py in the other.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wee-slack/wee-slack on GitHub