Debian系のpython-venvとかの話
Debian系で python3 -m ensurepip すると怒られる話とか、DebianにおけるPythonのパッケージングの話とか、書きたい。
Excluded are modules that cannot be included for licensing reasons, for dependency tracking purposes (for example the GPL-licensed gdbm module), or that should not be included for packaging reasons (for example the tk module which depends on Xorg and the venv module which depends on wheels to bootstrap pip). Modules that would interfere with system package management (for example ensurepip, when used outside virtual environments) are modified to print a message explaining the problem and recommending alternatives.
Except as described below, packages must not build or provide wheels. They are redundant to the established way of providing Python libraries to Debian users, take no advantage of distro-based tools, and are less convenient to use. E.g. they must be explicitly added to sys.path, cannot be easily grepped, and stack traces through Zip files are more difficult to debug.
A very limited set of wheel packages are available in the archive, but these support the narrow purpose of enabling the pip, virtualenv, and pyvenv tools in a Debian policy compliant way. These packages build their own dependent wheels through the use of the dirtbike “rewheeling” tool, which takes installed Debian packages and turns them back into wheels. (snip)
python3-venv/ensurepipデフォで依存しないの
ensurepipに必要なpython3-pipはmainでなくuniverseにあるし?
python3-pip-whlとかなに
既にpython3-pipやpython3-setuptoolsとしてパッケージングされているものをensurepipに内包するのがDebianのポリシー的に許容できないから、それぞれがwhlをバイナリパッケージとして生成するようにしておいて、ensurepip(python3-venv)はそれを参照する形にした、っぽい。
未解決
pipがあれこれvendoringしてるのはいいの(流石に諦めているような気もする)
余談