Due to a quite complex build, we use setuptools to build our C extension sabctools.
I wanted to distribute a sabctools.pyi file with it for typing information. but I got stuck:
When the wheel is installed it puts the sabctools.pyd (or .so, depende on platform) file in the main site-packages directory, so only when sabctools.pyi is in the same directory, it’s picked up by PyCharm etc as the valid typing file for the extension.
But I didn’t find a way to get pip to place the sabctools.pyi file in that directory.
Mostly I get the feeling this probably not how I should be making the wheel? Should the sabctools.pyd file be in a separate sabctools folder in site-packages which then can include the sabctools.pyi?
Our setup.py, for reference: sabctools/setup.py at master · sabnzbd/sabctools · GitHub
You should be able to make a little change to your extension module so that it’s built as a submodule of a package (a module with submodules, implemented by a directory containing __init__.py file), have the sabctools.pyi and py.typed files next to the extension module, and tell setuptools to package the whole package and its package data.
That worked indeed. Is that how a C extension is supposed to be configured from the start?
Unless I’m mistaken, this situation is essentially the same for any Python distribution artifact, pure or C extension. AFAIK, distributions that contain a top-level module cannot bundle a py.typed file or type stubs (or other non-importable assets) as there’s nowhere unambiguous to put them—they have to be an import packages for that (same with certain other limitations). It’s arguably a good idea to just make things import packages from the start, as it saves the pain of switching and providing backward compat if you end up needing any of that later.