release: publish as tlgr-cli, because PyPI will not take tlgr (2.0.1) - #20
Merged
Conversation
PyPI refuses the name `tlgr`: "This project name is too similar to an existing project". The project it means is `tlgrm`, first published 2026-06-14, one letter away and describing itself as a command-line client and webhook daemon for Telegram built on Telethon. tlgr's own 1.0.0 is tagged 2026-03-06, so the name here is not shadowing anything, but the similarity check does not weigh dates and there is no reason to wait on an appeal to have a working install line. The distribution name is the only thing that moves. It is not the import name and not the command: nothing in the source reads it, `[project.scripts]` is keyed on `tlgr.cli:cli`, and `[tool.setuptools.package-data]` is keyed on the package. So `import tlgr` still works, `tlgr --version` still works, every module path is untouched, and the wheel installs the same 951 commands it did yesterday. What changes is `pip install tlgr` becoming `pip install tlgr-cli`. The version goes to 2.0.1 rather than re-tagging 2.0.0, because 2.0.0 is released and its artefacts are named `tlgr-2.0.0`. A distribution cannot be renamed under a version that already exists; the wheel PyPI serves has to be the wheel the release page carries. The install docs are corrected in the same commit rather than after it. They said tlgr was not on PyPI, which was true when it was written this morning and stops being true with this release, and README's `pip install tlgr` was wrong for the whole of 1.x. docs/UPGRADING.md now also says plainly that `pipx upgrade tlgr` does not work for a v1 install, and to uninstall the old one only after the new one answers `--version`: both provide the same `tlgr` command and must not sit side by side.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PyPI refuses the name
tlgr:The project it means is
tlgrm, firstpublished 2026-06-14, one letter away, describing itself as a command-line
client and webhook daemon for Telegram built on Telethon. tlgr's own 1.0.0 is
tagged 2026-03-06, so the name here is not shadowing anything, but the
similarity check does not weigh dates. A separate request to PyPI asking for
tlgrto be permitted can run on its own time; this is so there is a workinginstall line today.
The distribution name is the only thing that moves
It is not the import name and it is not the command:
tlgr/ortests/reads the distribution name (noimportlib.metadata, nopkg_resources);[project.scripts]is keyed ontlgr.cli:cli;[tool.setuptools.package-data]is keyed on the packagetlgr.Verified on the built wheel:
So
import tlgrworks,tlgr --versionworks, every module path isuntouched, and the wheel installs the same commands it did yesterday. What
changes is
pip install tlgrbecomingpip install tlgr-cli.Why 2.0.1 and not a re-tag of 2.0.0
2.0.0 is released and its artefacts are named
tlgr-2.0.0. A distributioncannot be renamed under a version that already exists, and the wheel PyPI
serves has to be the wheel the release page carries.
Docs
Corrected in the same commit rather than after it. They said tlgr was not on
PyPI, which was true when written this morning and stops being true with this
release; README's
pip install tlgrwas wrong for the whole of 1.x.docs/UPGRADING.mdnow also says plainly thatpipx upgrade tlgrdoes notwork for a v1 install, and to uninstall the old one only after the new one
answers
--version— both provide the sametlgrcommand and must not sitside by side.
Verification
Locally against this branch: ruff clean, mypy clean (139 files), docs and
parity regenerate to no diff,
tools/release_notes.py v2.0.1agrees, andboth artefacts build as
tlgr_cli-2.0.1. Full suite running alongside CI.