DH_PYTHON2(1)
π DH_PYTHON2(1) π
okay bestie, sit down, hydrate, because we're doing the DH_PYTHON2(1) manual page and it's actually kind of iconic. this is dh_python2 β yes, the Debian helper that does your Python dependency math, drops maintainer scripts in so your files get byte compiled, all of that. it's giving β¨essential build infrastructureβ¨ and i'm obsessed. no cap.
β¨ NAME β¨
dh_python2 β calculates Python dependencies, adds maintainer scripts to byte compile files, etc.
like. that's the whole job description and honestly? slay.
π SYNOPSIS π
dh_python2 -p PACKAGE [-V [X.Y][-][A.B]] DIR_OR_FILE [-X REGEXPR]
π¦ DESCRIPTION π¦
πΈ QUICK GUIDE FOR MAINTAINERS πΈ
okay so here's the checklist, do them in order, don't skip, i will know:
- if necessary, describe supported Python versions via
X-Python-Versionfield indebian/control, - build depend on
dh-python - build-depend on
pythonorpython-allorpython-all-dev(>= 2.6.6-3~), - build module/application using its standard build system, remember to build extensions for all supported Python versions (loop over
pyversions -vr), - install files to the standard locations, add
--install-layout=debtosetup.py'sinstallcommand if your package is using distutils, - add
python2to dh's--withoption, or: - include
/usr/share/cdbs/1/class/python-distutils.mkindebian/rulesand depend oncdbs (>= 0.4.90), or: - call
dh_python2in thebinary-*target, - add
${python:Depends}toDepends
periodt. π
π NOTES π
so here's the tea: to support more than one Python version in the same binary package, dh_python2 (unlike dh_pycentral and dh_pysupport) creates symlinks to all supported Python versions at build time. what that means for you is: the second your list of supported Python versions changes, you need a binNMU (or a sourceful upload if we're talking architecture independent packages). it's the price of admission. but bestie β it's faster and more robust than its competitors, though. worth it. π₯
π dependencies π
dh_python2 tries to translate Python dependencies from the requires.txt file into Debian dependencies. in so many cases this just works with zero extra config, because dh_python2 ships with a build-in mapping of Python module names to Debian packages that gets periodically regenerated from the Debian archive. by default, the version information in the Python dependencies is discarded. so if you want dh_python2 to generate more strict dependencies (like, say, to avoid ABI problems), or if the automatic mapping is just not doing it for your package, you gotta hand dh_python2 some extra rules for translating Python module β Debian package dependencies.
so like, for a package python-foo that depends on a package python-bar, there are two files that may provide those rules:
- If the
python-foosource package ships with adebian/pydist-overridesfile, this file is used bydh_pythonduring the build ofpython-foo. - If the
python-barsource package ships with adebian/python-bar.pydistfile (and usesdh_python), this file will be included in the binary package as/usr/share/dh-python/dist/cpython2/python-bar. During the build ofpython-foo,dh_pythonwill then find and use the file.
both files have the same format, described in /usr/share/doc/dh-python/README.PyDist. and if all you want is to generate versioned dependencies (and we're assuming the python-bar package provides the pybar Python module), in most cases it'll be enough to put this line:
pybar python-bar; PEP386
into either of the above files. easy. π
π§ namespace feature π§
dh_python2 parses Egg's namespace_packages.txt files (in addition to the --namespace command line argument(s)) and drops empty __init__.py files from the binary package. pycompile will regenerate them at install time and pyclean will remove them at uninstall time (if they're no longer used in installed packages). still, it's a good idea to provide an __init__.py file in one of the binary packages (even if all the other packages use this feature). just saying. π
π private dirs π
/usr/share/foo, /usr/share/games/foo, /usr/lib/foo and /usr/lib/games/foo private directories are scanned for Python files by default (where foo is the binary package name). if your package ships Python files somewhere else entirely, just add another dh_python2 call in debian/rules with the directory name as an argument β and yes you can use a totally different set of options in that call. but if you need to change options (f.e. a list of supported Python versions) for a private directory that's checked by default, invoke dh_python2 with --skip-private and add another call with a path to this directory and your new options. π«Ά
π debug packages π
in binary packages whose name ends with -dbg, all files in /usr/lib/python2.X/{site,dist}-packages/ directory that have extensions different than so or h are removed by default. if you do not want that, use the --no-dbg-cleaning option to disable this feature.
π pyinstall files π
files listed in debian/pkg.pyinstall file will be installed as public modules (i.e. into .../dist-packages/ directory) for all requested Python versions (dh_install doesn't know about python's site- vs. dist-packages issue, bless it).
Syntax: path/to/file [NAMESPACE] [VERSION_RANGE]
the debian directory is automatically removed from the path, so you can place your files in debian/ directory and install them from this location (if you want to install them in the debian namespace, set NAMESPACE to debian). if NAMESPACE is set, all listed files will be installed in .../dist-packages/NAMESPACE/ directory.
Examples, my beloved:
foo.pyinstalls.../dist-packages/foo.pyfor all supported Python versionsfoo/bar.py 2.6-installs.../dist-packages/foo/bar.pyfor versions>= 2.6foo/bar.py spaminstalls.../dist-packages/spam/bar.pydebian/*.py spam.egg 2.5installs.../python2.5/site-packages/spam/egg/*.pyfiles
π pyremove files π
if you want to remove some public modules (i.e. files in .../dist-packages/ directory) installed by build system (from all supported Python versions or only from a subset of these versions), add them to debian/pkg.pyremove file.
Examples:
*.pthremoves.pthfiles from.../dist-packages/bar/baz.py 2.5removes.../python2.5/site-packages/bar/baz.py
π overriding supported / default Python versions π
if you want to override the system's list of supported Python versions or the default one (f.e. to build a package that includes symlinks for an older version of Python or compile .py files only for a given interpreter version), you can do that via the DEBPYTHON_SUPPORTED and/or DEBPYTHON_DEFAULT env. variables.
Example: 2.5,2.7 limits the list of supported Python versions to Python 2.5 and Python 2.7. main character energy, honestly. π
β¨ OPTIONS β¨
--versionβ show program's version number and exit-h,--helpβ show help message and exit--no-guessing-versionsβ disable guessing other supported Python versions--no-guessing-depsβ disable guessing dependencies--no-dbg-cleaningβ do not remove any files from debug packages--no-ext-renameβ do not add magic tags nor multiarch tuples to extension file names--no-shebang-rewriteβ do not rewrite shebangs--skip-privateβ don't check private directories-v,--verboseβ turn verbose mode on-i,--indepβ act on architecture independent packages-a,--archβ act on architecture dependent packages-q,--quietβ be quiet-p PACKAGE,--package=PACKAGEβ act on the package named PACKAGE-N NO_PACKAGE,--no-package=NO_PACKAGEβ do not act on the specified package-V VRANGEβ specify list of supported Python versions. seepycompile(1)for examples-X REGEXPR,--exclude=REGEXPRβ exclude items that match given REGEXPR. you may use this option multiple times to build up a list of things to exclude.--compile-allβ compile all files from given private directory inpostinst/rtupdate, not just the ones provided by the package (i.e. do not pass the--packageparameter topycompile/pyclean)--accept-upstream-versionsβ accept upstream versions while translating Python dependencies into Debian ones--depends=DEPENDSβ translate given requirements into Debian dependencies and add them to${python:Depends}. use it for missing items inrequires.txt--depends-section=SECTIONβ translate requirements from given sections ofrequres.txtfile into Debian dependencies and add them to${python:Depends}.--recommends=RECOMMENDSβ translate given requirements into Debian dependencies and add them to${python:Recommends}--recommends-section=SECTIONβ translate requirements from given sections ofrequres.txtfile into Debian dependencies and add them to${python:Recommends}.--suggests=SUGGESTSβ translate given requirements into Debian dependencies and add them to${python:Suggests}--suggests-section=SECTIONβ translate requirements from given sections ofrequres.txtfile into Debian dependencies and add them to${python:Suggests}.--requires=FILENAMEβ translate requirements from given file(s) into Debian dependencies and add them to${python:Depends}--namespace=NAMEβ use this option (multiple time if necessary) ifnamespace_packages.txtis not complete--ignore-namespaceβ ignore Egg's namespace declaration and--namespaceoption. this option will disable removing (and recreating at install time) empty__init__.pyfiles. removingnamespace_packages.txtfrom egg-info directory has the same effect.--clean-pycentralβ generate maintainer script that will remove byte code generated by python-central helper--shebang=COMMANDβ use given command as shebang in scripts--ignore-shebangsβ do not translate shebangs into Debian dependencies
π SEE ALSO π
/usr/share/doc/python/python-policy.txt.gz/usr/share/doc/dh-python/README.PyDistpybuild(1)pycompile(1),pyclean(1)dh_python3(1),py3compile(1),py3clean(1)- Wiki page about converting package to
dh_python2:http://wiki.debian.org/Python/TransitionToDHPython2 http://deb.li/dhp2β most recent version of this document
π AUTHOR π
Piotr OΕΌarowski, 2012-2013
and that's the whole page bestie!! π«Ά this was DH_PYTHON2(1) (yes, that's the manual name and the footer, it contains multitudes), written by Piotr OΕΌarowski, 2012-2013, and if you need the most recent version of this document it's at http://deb.li/dhp2. go forth and byte compile, you absolute icon. π
β¨π
π¦ where this page comes from
- ubuntu jammy: dh-python 5.20220403 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms