Conversation
The rename shipped in published 0.3.0 (package, dist, and the pythonlings command), but CLAUDE.md still documented the old pylings command, package paths, stylesheet, and entry point. Update them so contributors and agents run the command that actually ships. Bump to 0.3.1 (docs/packaging cleanup, no behavior change) and add the CHANGELOG entry. The unrelated pylings PyPI package belongs to a different project; pythonlings is the only command this project ships. Closes #24
cli.py hardcoded __version__ = "0.3.0" as a second version source separate from pyproject.toml, so 'pythonlings --version' reported the wrong number after the 0.3.1 bump. Read the version from installed package metadata instead, with a source-checkout fallback, so it can never drift from pyproject again. Surfaced while running the RELEASE.md pre-release checklist for 0.3.1.
docs: finish pylings → pythonlings rename in CLAUDE.md
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughVersion bumped from Changesv0.3.1 Release: Dynamic Versioning and Doc Rename Fixes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Promotes 0.3.1 to
mainfor tagging and release.pylingsrefs in CLAUDE.md + collision with unrelated PyPI package #24)pythonlings --versionfrom package metadata (was hardcoded, had drifted to 0.3.0)Verified: 123 tests pass locally, CI matrix (3.11/3.12/3.13) green on #26, built wheel smoke-tests as 0.3.1.
Summary by CodeRabbit
Bug Fixes
pythonlings --versionnow correctly reports the installed package version from metadatapylingstopythonlingsfor consistency across commands and documentationDocumentation
Version: v0.3.1