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.