Skip to content
CI & maintenance utilities for Python packages in Gentoo
Branch: master
Clone or download
mgorny gpy-drop-dead-impls: Disable PYTHON_COMPAT reading opt
Disable the optimization for reading PYTHON_COMPAT via USE flags.  It
obviously does not work when USE flags are removed for dead impls.
Latest commit b1ef11d Apr 17, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
gpyutils gpy-drop-dead-impls: Disable PYTHON_COMPAT reading opt Apr 17, 2019
.gitignore Add a script. Aug 5, 2013
COPYING Add the license text. Sep 5, 2013 Move migration tools to obsolete/, remove from dist May 14, 2017
README Add gpy-verify-installed-reqs, to find mismatched reqs May 22, 2017
gpy-depcheck Rewrite and fix gpy-depcheck. Aug 17, 2013
gpy-depgraph gpy-depgraph: Abstract out package API May 15, 2018
gpy-drop-dead-impls gpy-drop-dead-impls: Disable PYTHON_COMPAT reading opt Apr 17, 2019
gpy-find-missing-meta gpy-find-missing-meta: Fix distutils-r1 w/ single-impl Apr 20, 2017
gpy-impl gpy-impl: Fix usage error handling Mar 11, 2018
gpy-showimpls gpy-showimpls: Output redundancy (alike showkw but including pyimpls) May 14, 2017
gpy-verify-installed-reqs gpy-verify-installed-reqs: Remove IPython import (debug code) May 22, 2017
tox.ini Add tox.ini to ease cross-impl testing May 14, 2017




gpy-cands searches the tree for packages that could be updated to use the python-r1 suite eclasses. Technically, it either detects packages using the python.eclass or depending on the Python interpreter directly.

The output consists of the package followed by the currently used eclass and the suggested -r1 eclass.

The scan is done per-repository.


gpy-depcheck scans the tree for -r1 packages that do not use [${PYTHON_USEDEP}] on their -r1 dependencies. The intention of this script is to catch missing USE-dependencies but with the current design it can't distinguish between dependency omitted mistakenly and intentionally (unnecessary).

The output consists of the -r1 package followed by an indented list of its dependencies that lack [${PYTHON_USEDEP}].

The scan can done per-repository or per-package.


gpy-depgraph is an auxiliary tool to convert plain package lists into dependency graphs. It can be used to ease maintenance tasks by ordering them per-dependency.

The package list is either read from files (specified as parameters) or from stdin. The default output format is a .dot graph (suitable for further processing using GraphViz).

The operation is done using supplied package lists and a specified repository (to obtain dependencies). All packages must be available in the repository.


gpy-drop-dead-impls scans the tree for -r1 packages that are listing obsolete Python implementations in PYTHON_COMPAT. The script can optionally automatically remove those implementations from ebuilds.

The output is a plain list of packages. If --fix is used, script can also modify ebuilds.

The scan can be done per-repository or per-package.


gpy-find-missing-meta scans the repository for common mistakes in -r1 packages. The issues found include:

  • PYTHON_COMPAT declared in eclass,
  • missing PYTHON_DEPS in (R)DEPEND,
  • PYTHON_DEPS used in RDEPEND w/ python-any-r1.

It could be possibly amended with additional checks in the future.

The output consists of the -r1 package followed by a message explaining the issue.

The scan can done per-repository or per-package.


gpy-impl is a simple PYTHON_COMPAT mangler. It is based on the interface exposed by ekeyword.

It takes an ebuild path followed by one or more Python implementations, optionally prefixed using '-', '%' or '+'. The two former prefixes cause it to remove the specific implementation from PYTHON_COMPAT, otherwise the implementation is added to PYTHON_COMPAT. The script outputs a 'diff' of PYTHON_COMPAT afterwards.

The script operates on the specified file only.


gpy-showimpls lists the implementations supported by various versions of a package in a table. It is similar to eshowkw in that regard.

The output for each package slot consists of the package slot name followed by a table listing supported implementations. Supported implementations are color-coded for their importance. Unsupported are simply not listed.

gpy-showimpls prints three extra columns that annotate the ebuild with potentially useful extra information.

The first column explains the package keywords state. No symbol means no keywords (live ebuild likely), '~' means no stable keywords and 'S' means that the package has at least one stable keyword.

The second column explains the support for multiple implementations. No symbol means that the package supports multiple implementations (likewise python-r1), 's' denotes that only one implementation can be chosen (likewise python-single-r1) and 'a' denotes that any of supported implementations will be used (likewise python-any-r1).

The third column denotes the eclass suite used. No symbol means that python-r1 eclass is used, asterisk means that the 'python.eclass' is used. In this case, all untested implementations are listed as enabled and some of them may not actually work.

The scan can be done per-package only.


gpy-upgrade-impl is intended to help when considering 'upgrading' the default Python implementations. Given two implementations (the old one and the new one), it scans the tree for packages that support the old implementation but do not support the new one.

For example, gpy-upgrade-impl python{3_2,3_3} will list all packages that support Python 3.2 but do not work with Python 3.3.

Optionally, it may automatically add the new implementation to PYTHON_COMPAT (-r1 packages only). Please remember to read/test the ebuild afterwards since the implementation may have been omitted intentionally and the Python package may require patching.

The output is a plain list of packages. If --fix is used, script can also modify ebuilds.

The scan can be done per-repository or per-package.


A simple tool to help verifying that the package requirements (as seen by setuptools/pkg_resources) are satisfied for all installed packages. If they are not, entry_points installed by the package (or its dependencies) will not work and/or setuptools may attempt to fetch missing packages.

This tool takes no parameters. It processes all installed packages for the Python version it is started with and outputs all issues found, one per line.

You can’t perform that action at this time.