feat: migrate from runtime.txt to .python-version #434
Conversation
Replace legacy runtime.txt with .python-version for better tooling support and developer experience. Changes: - Add .python-version file with Python 3.13.3 - Update .gitignore to track .python-version - Modify GitHub Actions to use python-version-file parameter - Remove hardcoded PYTHON_VERSION env variable from CI - Add Python Version Management section to README - Add Dockerfile comments referencing .python-version - Delete runtime.txt Benefits: - Automatic version switching with pyenv/asdf/mise - Single source of truth for Python version - Simplified CI/CD configuration - Better alignment with modern Python ecosystem Closes #433
WalkthroughCreated and tracked a Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
Dockerfile (1)
5-5: Dockerfile comments reference specific patch version — consider making them version-agnostic.The added comments helpfully cross-reference
.python-versionto guide synchronization. However, including the specific version "(currently 3.13.3)" in the comments creates a maintenance burden. If.python-versionis updated (e.g., from 3.13.3 → 3.13 for security reasons), these comments become stale and misleading.Consider revising the comments to reference the file without the hardcoded version:
-# Python version should match .python-version file (currently 3.13.3) +# Python version should match .python-version fileThis keeps the intent clear while avoiding version duplication and staleness issues.
Additionally, if the
.python-versionversion is updated to use major.minor format (per the prior issue), the base image tags on lines 6 and 24 will need corresponding updates.Also applies to: 23-23
README.md (1)
22-26: README version specification may need updating if.python-versionversion changes.The new Python Version Management section is well-written and helpful. Line 26 hardcodes "Python 3.13.3," which risks becoming outdated if
.python-versionis updated. The parenthetical "(or the version specified in.python-version)" provides a good safety net, but consider simplifying to avoid dual-version statements:-Alternatively, ensure you have Python 3.13.3 (or the version specified in `.python-version`) installed. +Alternatively, ensure you have the Python version specified in `.python-version` installed.This keeps the README version-agnostic and eliminates duplication.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/python-app.yml(2 hunks).gitignore(2 hunks).python-version(1 hunks)Dockerfile(2 hunks)README.md(1 hunks)runtime.txt(0 hunks)
💤 Files with no reviewable changes (1)
- runtime.txt
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: edmorley
Repo: nanotaboada/python-samples-fastapi-restful PR: 419
File: .python-version:1-1
Timestamp: 2025-09-26T08:23:15.158Z
Learning: For Heroku deployments using .python-version files, Heroku strongly recommends specifying only the major Python version (e.g., "3.13") rather than exact patch versions. This allows apps to automatically receive Python security updates each time they build. The .python-version file supports both major version syntax (3.13) and exact patch version syntax (3.13.3), but the major version approach is the recommended best practice.
📚 Learning: 2025-09-26T08:23:15.158Z
Learnt from: edmorley
Repo: nanotaboada/python-samples-fastapi-restful PR: 419
File: .python-version:1-1
Timestamp: 2025-09-26T08:23:15.158Z
Learning: For Heroku deployments using .python-version files, Heroku strongly recommends specifying only the major Python version (e.g., "3.13") rather than exact patch versions. This allows apps to automatically receive Python security updates each time they build. The .python-version file supports both major version syntax (3.13) and exact patch version syntax (3.13.3), but the major version approach is the recommended best practice.
Applied to files:
Dockerfile.python-version.gitignoreREADME.md
📚 Learning: 2025-09-26T08:23:15.158Z
Learnt from: edmorley
Repo: nanotaboada/python-samples-fastapi-restful PR: 419
File: .python-version:1-1
Timestamp: 2025-09-26T08:23:15.158Z
Learning: For Heroku deployments, .python-version files should specify only major.minor versions (e.g., "3.13") rather than exact patch versions (e.g., "3.13.3"). Heroku's documentation explicitly recommends against specifying patch versions, allowing the platform to automatically use the latest patch version for security updates.
Applied to files:
.python-version.gitignoreREADME.md
📚 Learning: 2025-04-17T19:22:41.270Z
Learnt from: nanotaboada
Repo: nanotaboada/python-samples-fastapi-restful PR: 331
File: .github/workflows/python-app.yml:22-24
Timestamp: 2025-04-17T19:22:41.270Z
Learning: The wagoid/commitlint-github-action GitHub Action uses commitlint/config-conventional settings as a default fallback if no commitlint configuration file exists in the repository. This enforces Conventional Commits format with specific allowed types (build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test) and formatting rules.
Applied to files:
.github/workflows/python-app.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (3)
.gitignore (1)
89-89: Documentation improvement to .gitignore comment.The updated comment clearly explains why
.python-versionshould be tracked, improving developer understanding of the configuration decision..github/workflows/python-app.yml (1)
25-29: Workflow correctly delegates Python version to.python-versionfile.Both the lint (lines 25-29) and test (lines 51-55) jobs properly use
python-version-file: '.python-version'to read the version from the new.python-versionfile. The setup-python action will automatically parse the file and configure the correct Python version for each job. Caching viacache: 'pip'is preserved correctly.Please verify that any hardcoded
PYTHON_VERSIONenvironment variable references have been fully removed from the codebase and are not used in other workflows or scripts.Also applies to: 51-55
.python-version (1)
1-1: Original review comment's Heroku assumption does not apply to this project.This repository is not Heroku-deployed. The project uses Docker Compose for containerized deployment and
.python-versionfor local development tools (pyenv/asdf/mise), as documented in README.md. The migration fromruntime.txtto.python-versionreflects the change in development workflow tooling, not a Heroku deployment configuration.For Docker-based projects, exact patch version pinning (3.13.3) is a valid and appropriate practice—it ensures reproducible builds and consistent behavior across environments. Security updates for Python are managed via base image updates in the Dockerfile, not through
.python-versionchanges. The current cross-file consistency (.python-version, Dockerfile lines 5–6 and 23–24, README.md line 26) is correct and intentional.The original review comment's recommendation was based on Heroku best practices that do not apply here.
…i-restful into feature/python-version
|
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #434 +/- ##
=======================================
Coverage 89.65% 89.65%
=======================================
Files 3 3
Lines 116 116
=======================================
Hits 104 104
Misses 12 12
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/python-app.yml (1)
25-29: Approved: Successfully migrated topython-version-fileparameter.Both the lint and test jobs now properly use the
.python-versionfile via thepython-version-fileparameter, removing the hardcodedPYTHON_VERSIONenvironment variable. This establishes a single source of truth for Python version across local development and CI/CD.Minor note: Inconsistent
setup-pythonversions across jobs.The lint job uses
actions/setup-python@v6.0.0while the test job usesactions/setup-python@v6.1.0. For consistency and simpler maintenance, consider standardizing on a single version (e.g., both on v6.1.0). Both versions supportpython-version-file, so this is a style preference rather than a functional issue.Also applies to: 51-55
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/python-app.yml(2 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: edmorley
Repo: nanotaboada/python-samples-fastapi-restful PR: 419
File: .python-version:1-1
Timestamp: 2025-09-26T08:23:15.158Z
Learning: For Heroku deployments, .python-version files should specify only major.minor versions (e.g., "3.13") rather than exact patch versions (e.g., "3.13.3"). Heroku's documentation explicitly recommends against specifying patch versions, allowing the platform to automatically use the latest patch version for security updates.
Learnt from: edmorley
Repo: nanotaboada/python-samples-fastapi-restful PR: 419
File: .python-version:1-1
Timestamp: 2025-09-26T08:23:15.158Z
Learning: For Heroku deployments using .python-version files, Heroku strongly recommends specifying only the major Python version (e.g., "3.13") rather than exact patch versions. This allows apps to automatically receive Python security updates each time they build. The .python-version file supports both major version syntax (3.13) and exact patch version syntax (3.13.3), but the major version approach is the recommended best practice.
📚 Learning: 2025-04-17T19:22:41.270Z
Learnt from: nanotaboada
Repo: nanotaboada/python-samples-fastapi-restful PR: 331
File: .github/workflows/python-app.yml:22-24
Timestamp: 2025-04-17T19:22:41.270Z
Learning: The wagoid/commitlint-github-action GitHub Action uses commitlint/config-conventional settings as a default fallback if no commitlint configuration file exists in the repository. This enforces Conventional Commits format with specific allowed types (build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test) and formatting rules.
Applied to files:
.github/workflows/python-app.yml
📚 Learning: 2025-04-17T19:22:41.270Z
Learnt from: nanotaboada
Repo: nanotaboada/python-samples-fastapi-restful PR: 331
File: .github/workflows/python-app.yml:22-24
Timestamp: 2025-04-17T19:22:41.270Z
Learning: The wagoid/commitlint-github-action GitHub Action will use commitlint/config-conventional settings as a default fallback if no commitlint configuration file exists in the repository.
Applied to files:
.github/workflows/python-app.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (1)
.github/workflows/python-app.yml (1)
28-28: Verify.python-versionfile is properly created and tracked.The workflow now expects the
.python-versionfile to exist at the project root. Confirm that:
- The file has been created with the correct Python version (3.13.3 per PR objectives)
- It is tracked in git (
.gitignoreupdated to allow it)- No runtime.txt remains as a conflicting source of truth
Also applies to: 54-54
I've considered this approach, but I prefer to keep the full version 3.13.3 pinned for the following reasons: Reproducibility & Determinism:
Security & Control:
CI/CD Consistency:
Low Maintenance Burden:
While 3.13 would work fine for many projects, for this application the benefits of explicit versioning outweigh the convenience of automatic patch updates. We value predictability over convenience here. |
Replace legacy runtime.txt with .python-version for better tooling support and developer experience.
Changes:
Benefits:
Closes #433
This change is
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.