Re: Porting the icoextract package to pyproject.toml
Colin Watson <[email protected]> Wed, 29 Jul 2026 17:25:17 +0100
| Newsgroups | gmane.linux.debian.devel.python |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Jun 06, 2026 at 03:31:37PM -0700, James Lu wrote: >I'm running into some issues porting my icoextract package to >pyproject.toml. I've gotten it to build and function with >pybuild-plugin-pyproject, but it required some hacks along the way. >However, I'm not sure if I'm seeing bugs/limitations in the toolchain, >or I'm using the tools in some non-standard manner. > >I've staged the changes at https://salsa.debian.org/jlu/icoextract/-/tree/debian/experimental?ref_type=heads. >(Disclaimer: I am also the upstream author) > >1) The .deb package seems to leave behind >/usr/lib/python3/dist-packages/build/lib/icoextract. I can remove it >manually with an execute_after_dh_auto_install rule, but it doesn't >feel like this should be necessary. I've attached what the file list >looks like without the rm -rf rule. This usually happens because the setuptools configuration in your pyproject.toml fails to exclude the "build" directory, which becomes a problem when the packaging builds for two different Python versions. The typical fix is to change this: [tool.setuptools.packages.find] exclude = ["tests"] ... to this: [tool.setuptools.packages.find] include = ["icoextract", "icoextract.*"] >2) lintian complains about additional files in >/usr/lib/python3.14/dist-packages/icoextract-0.3.0.dist-info/. The >rest of the source files are installed to >/usr/lib/python3/dist-packages/icoextract/, which is what I expect >from previous versions currently in the archive. This is a side-effect of 1). >3) `export PYBUILD_INSTALL_ARGS=--install-scripts=debian/tmp` doesn't >seem to do anything now. I think that might be because >--install-scripts is a setup.py specific feature, but the wiki is >still hinting at this approach for packaging programs[1][2]. In my >case, I'm fine with changing python3-icoextract to contain the library >& CLI utils, and making icoextract a meta-package instead. AFAICT most >distros did not bother to split the package at all. If this is still a problem after fixing 1), consider just moving the relevant files around in an execute_after_dh_auto_install rule in debian/rules. Much easier.