Update Guide to 3bc27da

Signed-off-by: Michał Górny <mgorny@gentoo.org>

1 files changed, 19 insertions, 10 deletions

diff --git a/guide/_sources/distutils.rst.txt b/guide/_sources/distutils.rst.txt
index 51d8ca5..e4ca96f 100644
--- a/guide/_sources/distutils.rst.txt
+++ b/guide/_sources/distutils.rst.txt
@@ -109,8 +109,9 @@ that matches the top directory inside the archive, e.g.:
 Note that unlike sdist archives, snapshots are often missing generated
 files.  This has some implications, notably:
 
-1. If the package uses setuptools_scm, the version string needs
-   to be provided explicitly, cf. `setuptools_scm and snapshots`_.
+1. If the package uses setuptools_scm or a similar package, the version
+   string needs to be provided explicitly,
+   cf. `setuptools_scm (flit_scm, hatch-vcs) and snapshots`_.
 
 2. If the package uses Cython, the C files need to be generated
    and an explicit ``BDEPEND`` on ``dev-python/cython`` needs to
@@ -361,9 +362,12 @@ and other packages tend to copy that mistake.
 
 
 .. index:: SETUPTOOLS_SCM_PRETEND_VERSION
+.. index:: flit_scm
+.. index:: hatch-vcs
+.. index:: setuptools_scm
 
-setuptools_scm and snapshots
-============================
+setuptools_scm (flit_scm, hatch-vcs) and snapshots
+==================================================
 setuptools_scm_ is a package providing additional features for running
 inside a VCS checkout, in particular the ability to determine version
 from VCS tags.  However, this works correctly only when the package
@@ -401,7 +405,12 @@ via ``SETUPTOOLS_SCM_PRETEND_VERSION``::
 
     export SETUPTOOLS_SCM_PRETEND_VERSION=${PV}
 
+The flit_scm_ and hatch-vcs_ packages are both built on top
+of setuptools_scm.  The same approach applies to both of them.
+
 .. _setuptools_scm: https://pypi.org/project/setuptools-scm/
+.. _flit_scm: https://pypi.org/project/flit_scm/
+.. _hatch-vcs: https://pypi.org/project/hatch-vcs/
 
 
 .. index:: Cython
@@ -1449,8 +1458,7 @@ When this mode is used, the following applies:
 - no dependencies on a build backend or PEP 517 machinery are declared
   (``DISTUTILS_DEPS`` are empty)
 
-- the default implementations ``distutils-r1_python_compile``
-  and ``distutils-r1_python_install`` are no-ops
+- the default implementation, ``distutils-r1_python_compile`` is a no-op
 
 However, the following eclass features are still available:
 
@@ -1461,8 +1469,8 @@ However, the following eclass features are still available:
   phase to use (but the ebuild needs to install files there explicitly)
 
 - the contents of ``${BUILD_DIR}/install`` are merged into ``${D}``
-  post ``src_install`` (if it is present, temporary venv files are
-  removed)
+  by ``distutils-r1_python_install`` (if present; temporary venv files
+  are removed)
 
 - ``distutils_enable_sphinx`` and ``distutils_enable_tests``
   are functional
@@ -1474,7 +1482,7 @@ The simplest approach towards installing packages manually is to use
 ``python_domodule`` in ``python_compile`` sub-phase.  This causes
 the modules to be installed into ``${BUILD_DIR}/install`` tree,
 effectively enabling them to be picked up for the test phase
-and merging post ``src_install``.
+and merged in ``distutils-r1_python_install``.
 
 An example ebuild using a combination of GitHub archive (for tests)
 and PyPI wheel (for generated .dist-info) follows:
@@ -1542,7 +1550,8 @@ An example ebuild follows:
     }
 
 It is also valid to combine both approaches, e.g. install Python modules
-in ``python_compile``, and scripts in ``python_install``.
+in ``python_compile``, and scripts in ``python_install``.  In this case,
+``distutils-r1_python_install`` needs to be called explicitly.
 
 
 Integrating with a non-PEP 517 build system