consider glib development binaries usable without external python modules
!3740 (merged) and !3752 (merged) introduced a dependency on a Python module that is not part of a standard/minimal python3 interpreter. This introduces a dependency both at glib build time, but also a runtime dependency for users that need to run gdbus-codegen
The gdbus-codegen
script has a shebang that is typically #!/usr/bin/env python3
. Even if the dependency on the packaging
python module is handled by a package manager, leaving it to use an interpreter from the environment does not guarantee that the interpreter will be able to resolve the dependency, for example is the user is invoking this utility with an arbitrary python3 virtual environment activated on their shell, where packaging
is not installed. Distro maintainers will have to patch the shebang to point to the distro-managed python distribution, e.g. Debian/Ubuntu have this as /usr/bin/python3
, but others may not (examples: homebrew, msys2).
Prior to the changes, which were motivated by Python 3.12 removing distutils
- the gdbus-codegen
was mostly self contained, and it was overwhelmingly likely that any minimal python3 distribution would run the script. Now it requires an "external" python module, complicating the package distribution story, as gdbus-codegen
is now dependent not only on a Python 3 interpreter, but on a python distribution with additional dependencies.
I would consider some options to mitigate this - such as using distutils for Python interpreters < 3.12 (which does not solve the problem completely), or implementing/vendoring in code with the required functionality: it appears only a small slice of packaging
is required for this.