Merge pull request #1329 from sinoroc/add-glossary-build-backend-frontend

Add build backend and frontend to the glossary

Author: webknjaz

source/flow.rst

@@ -82,9 +82,12 @@ For example, here is a table for using :ref:`hatch`:
     requires = ["hatchling"]
     build-backend = "hatchling.build"
 
-With such a table in the :file:`pyproject.toml` file, a "frontend" tool like
-:ref:`build` can run your chosen build tool's "backend" to create the build
-artifacts. Your build tool may also provide its own frontend. An install tool
+With such a table in the :file:`pyproject.toml` file,
+a ":term:`frontend <Build Frontend>`" tool like
+:ref:`build` can run your chosen
+build tool's ":term:`backend <Build Backend>`"
+to create the build artifacts.
+Your build tool may also provide its own frontend. An install tool
 like :ref:`pip` also acts as a frontend when it runs your build tool's backend
 to install from a source distribution.
 

source/glossary.rst

@@ -12,6 +12,36 @@ Glossary
         extensions.
 
 
+    Build Backend
+
+        A library that takes a source tree or
+        :term:`source distribution <Source Distribution (or "sdist")>`
+        and builds a source distribution or :term:`wheel <Wheel>` from it.
+        The build is delegated to the backend by a
+        :term:`frontend <Build Frontend>`.
+        All backends offer a standardized interface.
+
+        Examples of build backends are
+        :ref:`flit's flit-core <flit>`,
+        :ref:`hatch's hatchling <hatch>`,
+        :ref:`maturin`,
+        :ref:`meson-python`,
+        :ref:`scikit-build-core`,
+        and :ref:`setuptools`.
+
+
+    Build Frontend
+
+        A tool that users might run
+        that takes arbitrary source trees or
+        :term:`source distributions <Source Distribution (or "sdist")>`
+        and builds source distributions or :term:`wheels <Wheel>` from them.
+        The actual building is delegated to each source tree's
+        :term:`build backend <Build Backend>`.
+
+        Examples of build frontends are :ref:`pip` and :ref:`build`.
+
+
     Built Distribution
 
         A :term:`Distribution <Distribution Package>` format containing files

source/key_projects.rst

@@ -140,7 +140,7 @@ hatch
 
 Hatch is a unified command-line tool meant to conveniently manage
 dependencies and environment isolation for Python developers. Python
-package developers use Hatch and its build backend Hatchling to
+package developers use Hatch and its :term:`build backend <Build Backend>` Hatchling to
 configure, version, specify dependencies for, and publish packages
 to PyPI. Its plugin system allows for easily extending functionality.
 

source/specifications/declaring-project-metadata.rst

@@ -27,7 +27,7 @@ table which are not defined by this specification. For tools wishing
 to store their own settings in ``pyproject.toml``, they may use the
 ``[tool]`` table as defined in the
 :ref:`build dependency declaration specification <declaring-build-dependencies>`.
-The lack of a ``[project]`` table implicitly means the build back-end
+The lack of a ``[project]`` table implicitly means the :term:`build backend <Build Backend>`
 will dynamically provide all keys.
 
 The only keys required to be statically defined are:

source/specifications/source-distribution-format.rst

@@ -43,7 +43,8 @@ The name and version components of the filename MUST match the values stored
 in the metadata contained in the file.
 
 Code that produces a source distribution file MUST give the file a name that matches
-this specification. This includes the ``build_sdist`` hook of a build backend.
+this specification. This includes the ``build_sdist`` hook of a
+:term:`build backend <Build Backend>`.
 
 Code that processes source distribution files MAY recognise source distribution files
 by the ``.tar.gz`` suffix and the presence of precisely *one* hyphen in the filename.

source/tutorials/packaging-projects.rst

@@ -108,7 +108,7 @@ Choosing a build backend
 
 Tools like :ref:`pip` and :ref:`build` do not actually convert your sources
 into a :term:`distribution package <Distribution Package>` (like a wheel);
-that job is performed by a *build backend*. The build backend determines how
+that job is performed by a :term:`build backend <Build Backend>`. The build backend determines how
 your project will specify its configuration, including metadata (information
 about the project, for example, the name and tags that are displayed on PyPI)
 and input files. Build backends have different levels of functionality, such as
@@ -127,7 +127,7 @@ table for :ref:`metadata <configuring metadata>`.
    management, as well as building, uploading, and installing packages. This
    tutorial uses single-purpose tools that work independently.
 
-The :file:`pyproject.toml` tells "front end" build tools like :ref:`pip` and
+The :file:`pyproject.toml` tells :term:`build frontend <Build Frontend>` tools like :ref:`pip` and
 :ref:`build` which backend to use for your project. Below are some
 examples for common build backends, but check your backend's own documentation
 for more details.
@@ -166,7 +166,7 @@ for more details.
 
 
 The ``requires`` key is a list of packages that are needed to build your package.
-The frontend should install them automatically when building your package.
+The :term:`frontend <Build Frontend>` should install them automatically when building your package.
 Frontends usually run builds in isolated environments, so omitting dependencies
 here may cause build-time errors.
 This should always include your backend's package, and might have other build-time