GitHub
08/27/2026, 11:17 AMpython setting or the project-level python setting, falling back to whatever Python
is running Meltano itself. This adds a third fallback in between: a .python-version
file in the project root, following the same one-version-per-first-line convention as
pyenv and uv.
Precedence is plugin setting, then project setting, then the file, then the system
Python, matching the ordering suggested in the issue, so a .python-version file some
teams already keep around for other tools won't override anything explicitly configured
in meltano.yml.
Added a python_version property on Project, modeled on the existing dotenv
handling in the same class, wired it into the one place VenvBackend resolves which
Python to use, and extended the existing precedence test plus a dedicated test for the
property itself. Also updated the settings docs where this fallback chain is explained
to users.
Ran the full pre-commit, typing (mypy + ty), and pytest sessions locally, all green.
Checklist
• I have read the contribution guide
Was generative AI tooling used to co-author this PR?
• Yes (please specify the tool below)
Generated-by: Claude Code following the agentic coding guidelines
Related Issues
• Closes #9851
Summary by Sourcery
Add .python-version support for selecting plugin virtual environment Python versions without overriding explicit Meltano settings.
New Features:
• Support using a project's .python-version file as a fallback Python version for plugin virtual environments.
Enhancements:
• Apply Python version precedence of plugin setting, project setting, .python-version file, then the system Python.
• Expose the project's pinned Python version and document the supported first-line convention.
Documentation:
• Update settings documentation to describe .python-version fallback behavior and precedence.
Tests:
• Add coverage for .python-version parsing and Python version precedence during virtual environment creation.
meltano/meltanoGitHub
08/27/2026, 10:47 PM