Browse Source

concept: We can remove pkgutil-style namespaces

Signed-off-by: Michał Górny <mgorny@gentoo.org>
master
Michał Górny 10 months ago
parent
commit
49046f90d0
No known key found for this signature in database GPG Key ID: 639ADAE2329E240E
  1. 78
      concept.rst

78
concept.rst

@ -112,65 +112,41 @@ More general information on the topic can be found under `packaging
namespace packages`_ in Python Packaging User Guide.
Namespace packages in Python 3
------------------------------
Since all supported Python versions in Gentoo support PEP-0420
namespaces, the other two methods are technically unnecessary. However,
the incompatibility between pkg_resources namespaces and the other two
methods makes removing them non-trivial.
If all packages within the namespace are using only pkgutil-style
namespaces, you can safely remove the dependencies on the package
providing the namespace and the package itself. Even partial removal
should not cause any issues. However, if the package was explicitly
provided upstream, note that some packages may carry an explicit
dependency on it and that dependency would need to be removed or made
conditional to Python < 3.3. You will also need to strip colliding
``__init__.py`` files.
If setuptools-style namespace are used, the namespace packages need
to remain as-is for the time being, as otherwise tests relying
on the namespaced packages are going to be broken. We have not yet
conceived a way forward for them.
Packaging pkgutil-style namespaces in Gentoo
--------------------------------------------
Normally all packages using the same pkgutil-style namespace install
its ``__init__.py`` file causing package collisions. In order
to resolve them, you need to move this file into a dedicated common
package.
Sometimes upstream already provides such a package (e.g.
``dev-python/backports``), or has a single common package
that can be used to install the namespace. If this is not the case,
you should create a new package named ``dev-python/namespace-<name>``.
The commonly copied code to install namespace follows:
.. code-block:: bash
:emphasize-lines: 26-29,33
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
PYTHON_COMPAT=( pypy3 python{2_7,3_{6,7,8}} )
inherit python-r1
DESCRIPTION="Namespace package declaration for jaraco"
HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Python/Namespace_packages"
SRC_URI=""
LICENSE="public-domain"
SLOT="0"
KEYWORDS="~alpha amd64 ~arm arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc x86"
IUSE=""
REQUIRED_USE="${PYTHON_REQUIRED_USE}"
RDEPEND="
!<dev-python/jaraco-packaging-5.1
${PYTHON_DEPS}
"
DEPEND="${PYTHON_DEPS}"
src_unpack() {
mkdir -p "${S}"/jaraco || die
cat > "${S}"/jaraco/__init__.py <<-EOF || die
__path__ = __import__('pkgutil').extend_path(__path__, __name__)
EOF
}
src_install() {
python_foreach_impl python_domodule jaraco
}
Usually, you will also have to strip the colliding ``__init__.py``
from packages installing into this namespace:
its ``__init__.py`` file causing package collisions. As having this
file is no longer necessary for Python 3.3 and newer, the recommended
solution is to strip it before installing the package. The presence
of this file is harmless during build and testing.
.. code-block:: bash
python_install() {
rm "${BUILD_DIR}"/lib/jaraco/__init__.py || die
distutils-r1_python_install --skip-build
distutils-r1_python_install
}

Loading…
Cancel
Save