Merge branch 'main' into translation/source

Author: github-actions[bot]

source/guides/packaging-binary-extensions.rst

@@ -403,3 +403,15 @@ a Debian system, see the following articles:
 * `What are (c)python extension modules? <https://thomasnyberg.com/what_are_extension_modules.html>`_
 * `Releasing the gil <https://thomasnyberg.com/releasing_the_gil.html>`_
 * `Writing cpython extension modules using C++ <https://thomasnyberg.com/cpp_extension_modules.html>`_
+
+Additional considerations for binary wheels
+-------------------------------------------
+
+The `pypackaging-native <https://pypackaging-native.github.io/>`_ website has
+additional coverage of packaging Python packages with native code. It aims to
+provide an overview of the most important packaging issues for such projects,
+with in-depth explanations and references.
+
+Examples of topics covered are non-Python compiled dependencies ("native
+dependencies"), the importance of the ABI (Application Binary Interface) of
+native code, dependency on SIMD code and cross compilation.

source/guides/writing-pyproject-toml.rst

@@ -22,19 +22,19 @@ three possible TOML tables in this file.
 
 .. note::
 
-   There is a significant difference between the ``[build-system]`` and
-   ``[project]`` tables. The former should always be present, regardless of
-   which build backend you use (since it *defines* the tool you use). The latter
-   is understood by *most* build backends, but some build backends use a
-   different format.
+   The ``[build-system]`` table should always be present,
+   regardless of which build backend you use (``[build-system]`` *defines* the
+   build tool you use).
 
-   At the time of writing this (November 2023), Poetry_ is a notable build
-   backend that does not use the ``[project]`` table (it uses the
-   ``[tool.poetry]`` table instead).
+   On the other hand, the ``[project]`` table is understood by *most* build
+   backends, but some build backends use a different format.
 
+   As of August 2024, Poetry_ is a notable build backend that does not use
+   the ``[project]`` table, it uses the ``[tool.poetry]`` table instead.
    Also, the setuptools_ build backend supports both the ``[project]`` table,
-   and the older format in ``setup.cfg`` or ``setup.py``. For new projects, it
-   is recommended to use the ``[project]`` table, and keep ``setup.py`` only if
+   and the older format in ``setup.cfg`` or ``setup.py``.
+
+   For new projects, use the ``[project]`` table, and keep ``setup.py`` only if
    some programmatic configuration is needed (such as building C extensions),
    but the ``setup.cfg`` and ``setup.py`` formats are still valid. See
    :ref:`setup-py-deprecated`.