Skip to content
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

Closed
edmorley opened this issue Feb 28, 2023 · 0 comments · Fixed by #272
Closed

Automatic Python patch version updates #9

edmorley opened this issue Feb 28, 2023 · 0 comments · Fixed by #272
Assignees
Labels
enhancement New feature or request

Comments

@edmorley
Copy link
Member

edmorley commented Feb 28, 2023

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:

GUS-W-11475071.

@edmorley edmorley added the enhancement New feature or request label Feb 28, 2023
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.
@edmorley edmorley self-assigned this Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant