-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic Python patch version updates #9
Labels
enhancement
New feature or request
Comments
edmorley
added a commit
that referenced
this issue
Sep 16, 2024
This adds support for configuring the app's Python version using a `.python-version` file. This file is used by several tools in the Python ecosystem (such as pyenv, `actions/setup-python`, uv), whereas the existing `runtime.txt` file is proprietary to Heroku. We support the following `.python-version` syntax: - Major Python version (eg `3.12`, which will then be resolved to the latest Python 3.12). (This form is recommended, since it allows for Python security updates to be pulled in without having to manually bump the version.) - Exact Python version (eg `3.12.6`) - Comments (lines starting with `#`) - Blank lines We don't support the following `.python-version` features: - Specifying multiple Python versions - Prefixing versions with `python-` (since this form is undocumented and will likely be deprecated in the future) For now, if both a `runtime.txt` file and a `.python-version` file are present, then the `runtime.txt` file will take precedence. In the future, support for `runtime.txt` will eventually be deprecated (and eventually removed) in favour of the `.python-version` file. Since the `.python-version` file (unlike `runtime.txt`) supports specifying just the Python major version, adding support also required: - adding a mapping of major versions to the latest patch releases - explicit handling for EOL/unrecognised major versions - adding the concept of a "requested Python version" vs the resolved Python version (which should hopefully tie in well with use of a manifest in the future) In addition, the "origin" of a Python version now has to be tracked, so that build output can state which file was used, or in the case of invalid version errors, which file needs fixing by the user. Closes #6. Closes #9. GUS-W-12151504. GUS-W-11475071.
edmorley
added a commit
that referenced
this issue
Sep 16, 2024
This adds support for configuring the app's Python version using a `.python-version` file. This file is used by several tools in the Python ecosystem (such as pyenv, `actions/setup-python`, uv), whereas the existing `runtime.txt` file is proprietary to Heroku. For now, if both a `runtime.txt` file and a `.python-version` file are present, then the `runtime.txt` file will take precedence. In the future, support for `runtime.txt` will eventually be deprecated (and eventually removed) in favour of the `.python-version` file. We support the following `.python-version` syntax: - Major Python version (eg `3.12`, which will then be resolved to the latest Python 3.12). (This form is recommended, since it allows for Python security updates to be pulled in without having to manually bump the version.) - Exact Python version (eg `3.12.6`) - Comments (lines starting with `#`) - Blank lines We don't support the following `.python-version` features: - Specifying multiple Python versions - Prefixing versions with `python-` (since this form is undocumented and will likely be deprecated in the future) Since the `.python-version` file (unlike `runtime.txt`) supports specifying just the Python major version, adding support also required: - adding a mapping of major versions to the latest patch releases - explicit handling for EOL/unrecognised major versions - adding the concept of a "requested Python version" vs the resolved Python version (which should hopefully tie in well with use of a manifest in the future) In addition, the "origin" of a Python version now has to be tracked, so that build output can state which file was used, or in the case of invalid version errors, which file needs fixing by the user. Closes #6. Closes #9. GUS-W-12151504. GUS-W-11475071.
edmorley
added a commit
that referenced
this issue
Sep 16, 2024
This adds support for configuring the app's Python version using a `.python-version` file. This file is used by several tools in the Python ecosystem (such as pyenv, `actions/setup-python`, uv), whereas the existing `runtime.txt` file is proprietary to Heroku. For now, if both a `runtime.txt` file and a `.python-version` file are present, then the `runtime.txt` file will take precedence. In the future, support for `runtime.txt` will be deprecated (and eventually removed) in favour of the `.python-version` file. We support the following `.python-version` syntax: - Major Python version (e.g. `3.12`, which will then be resolved to the latest Python 3.12). (This form is recommended, since it allows for Python security updates to be pulled in without having to manually bump the version.) - Exact Python version (e.g. `3.12.6`) - Comments (lines starting with `#`) - Blank lines We don't support the following `.python-version` features: - Specifying multiple Python versions - Prefixing versions with `python-` (since this form is undocumented and will likely be deprecated in the future) Since the `.python-version` file (unlike `runtime.txt`) supports specifying just the Python major version, adding support also required: - adding a mapping of major versions to the latest patch releases - explicit handling for EOL/unrecognised major versions - adding the concept of a "requested Python version" vs the resolved Python version (which should hopefully tie in well with use of a manifest in the future) In addition, the "origin" of a Python version now has to be tracked, so that build output can state which file was used, or in the case of invalid version errors, which file needs to be fixed by the user. Closes #6. Closes #9. GUS-W-12151504. GUS-W-11475071.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the user has to either:
(a) not specify a Python version (in which case they get the default)
(b) specify an exact version (such as
3.10.5
)In order to make it easier for users to keep on an up to date Python release, it would be helpful if we also supported specifying just a major version (eg
3.11
), which the buildpack would automatically map back to the latest patch release.See also:
.python-version
file #6GUS-W-11475071.
The text was updated successfully, but these errors were encountered: