Descartando suporte para versões mais antigas do Python¶
The ability to drop support for older Python versions is enabled by the standard Especificações de metadados principais 1.2 specification via the “Requires-Python” attribute.
Metadata 1.2+ installers, such as Pip, will adhere to this specification by matching the current Python runtime and comparing it with the required version in the package metadata. If they do not match, it will attempt to install the last package distribution that supported that Python runtime.
This mechanism can be used to drop support for older Python versions, by amending the Requires-Python attribute in the package metadata.
Requisitos¶
This workflow requires that the user installing the package uses Pip [1], or another installer that supports the Metadata 1.2 specification.
Lidando com os wheels universais¶
Traditionally, Setuptools projects providing Python code that is semantically
compatible with both Python 2 and Python 3, produce wheels that have a py2.py3 tag in their names. When dropping
support for Python 2, it is important not to forget to change this tag
to just py3. It is often configured within setup.cfg under
the [bdist_wheel] section by setting universal = 1.
Se você usar este método, remova esta opção ou seção, ou defina explicitamente universal como 0:
# setup.cfg
[bdist_wheel]
universal = 0 # Make the generated wheels have "py3" tag
Dica
Regarding deprecated direct setup.py invocations,
passing the --universal flag on the command line could override this setting.
Definindo a versão Python exigida¶
1. Install twine¶
Ensure that you have twine available at its latest version. Steps:
python3 -m pip install --upgrade twine
py -m pip install --upgrade twine
2. Especifique os intervalos de versão para distribuições Python suportadas¶
Set the version ranges declaring which Python distributions are supported
within your project’s pyproject.toml. The requires-python configuration field
corresponds to the Requires-Python core metadata field:
[build-system]
...
[project]
requires-python = ">= 3.8" # At least Python 3.8
You can specify version ranges and exclusion rules (complying with the Especificadores de versão specification), such as at least Python 3.9. Or, at least Python 3.7 and beyond, skipping the 3.7.0 and 3.7.1 point releases:
requires-python = ">= 3.9"
requires-python = ">= 3.7, != 3.7.0, != 3.7.1"
If using the Setuptools build backend, consult the dependency-management documentation for more options.
Cuidado
Avoid adding upper bounds to the version ranges, e. g. ">= 3.8, < 3.10". Doing so can cause different errors
and version conflicts. See the discourse-discussion for more information.
3. Validando o Metadata antes de publicar¶
Dentro de um pacote fonte Python (o arquivo zip ou tar-gz que você baixou) está um arquivo de texto chamado PKG-INFO.
This file is generated by the build backend when it generates the source package. The file contains a set of keys and values, the list of keys is part of the PyPA standard metadata format.
Você pode ver o conteúdo do arquivo gerado assim:
tar xfO dist/my-package-1.0.0.tar.gz my-package-1.0.0/PKG-INFO
Valide que o seguinte está no lugar, antes de publicar o pacote:
If you have upgraded correctly, the
Metadata-Versionvalue should be 1.2 or higher.The
Requires-Pythonfield is set and matches your specification in the configuration file.
4. Publishing the package¶
Proceed as suggested in Enviando seu Projeto para PyPI.
Dropping a Python version¶
In principle, at least metadata support for Python versions should be kept as long as possible, because
once that has been dropped, people still depending on a version will be forced to downgrade.
If however supporting a specific version becomes a blocker for a new feature or other issues occur, the metadata
Requires-Python should be amended. Of course this also depends on whether the project needs to be stable and
well-covered for a wider range of users.
Each version compatibility change should have its own release.