What Happened?
Running pylings executes stale / unrelated PyPI code instead of this project. Investigating turned up two things:
-
Stale contributor docs. The pylings → pythonlings rename landed in 0.3.0 — the package directory, the PyPI dist name, and the console script are all pythonlings (pyproject.toml: pythonlings = "pythonlings.cli:main"). But CLAUDE.md still documents the old pylings command and pylings/ package paths throughout (lines 16, 21, 27, 30, 41, 50, 51). Anyone — human or agent — following it runs a command that no longer exists.
-
Name collision with an unrelated project. The old pylings name clashes file-for-file with an unrelated pylings project on PyPI (pylings 1.0.4) and with this project's own former name (python-learnings 0.2.0). When those are installed in the same environment, a pylings/ site-packages directory and a pylings console script get clobbered together (both register pylings = pylings.*:main). This is exactly why the project moved to pythonlings; the docs just hadn't caught up.
Steps To Reproduce
- In an environment that has
python-learnings 0.2.0 and/or pylings 1.0.4 installed (but not pythonlings), run pylings.
- Observe it runs old / foreign code, not this repo.
- Open
CLAUDE.md → it instructs pylings init, pylings run ..., etc., but pyproject.toml only ships the pythonlings command.
Expected Behavior
- All contributor docs reference the
pythonlings command and the pythonlings/ package.
- The only supported install path is
pip install pythonlings (or pip install -e ".[dev]" for dev), which exposes the pythonlings command. The unrelated pylings PyPI name is never required or referenced as our command.
Environment
- OS: macOS (Darwin 25.5.0)
- Python: 3.9 (miniconda)
- Terminal: —
- Pythonlings version: repo at 0.3.0; the offending env had
python-learnings 0.2.0 + unrelated pylings 1.0.4 installed, and no pythonlings.
Fix: correct the stale pylings references in CLAUDE.md, and document the clean-install path. Tracked for the 0.3.1 release.
What Happened?
Running
pylingsexecutes stale / unrelated PyPI code instead of this project. Investigating turned up two things:Stale contributor docs. The
pylings → pythonlingsrename landed in 0.3.0 — the package directory, the PyPI dist name, and the console script are allpythonlings(pyproject.toml:pythonlings = "pythonlings.cli:main"). ButCLAUDE.mdstill documents the oldpylingscommand andpylings/package paths throughout (lines 16, 21, 27, 30, 41, 50, 51). Anyone — human or agent — following it runs a command that no longer exists.Name collision with an unrelated project. The old
pylingsname clashes file-for-file with an unrelatedpylingsproject on PyPI (pylings1.0.4) and with this project's own former name (python-learnings0.2.0). When those are installed in the same environment, apylings/site-packages directory and apylingsconsole script get clobbered together (both registerpylings = pylings.*:main). This is exactly why the project moved topythonlings; the docs just hadn't caught up.Steps To Reproduce
python-learnings0.2.0 and/orpylings1.0.4 installed (but notpythonlings), runpylings.CLAUDE.md→ it instructspylings init,pylings run ..., etc., butpyproject.tomlonly ships thepythonlingscommand.Expected Behavior
pythonlingscommand and thepythonlings/package.pip install pythonlings(orpip install -e ".[dev]"for dev), which exposes thepythonlingscommand. The unrelatedpylingsPyPI name is never required or referenced as our command.Environment
python-learnings0.2.0 + unrelatedpylings1.0.4 installed, and nopythonlings.Fix: correct the stale
pylingsreferences inCLAUDE.md, and document the clean-install path. Tracked for the 0.3.1 release.