Stubgen during packaging

[nicholasjng]

I have a question (relevant to nanobind-bazel in a way) about stubgen.py.

Bazel puts the built .so extensions into a "bindir" (i.e. a bin/ folder under the output dir + symlink prefix), keeping the directory structure of where the BUILD files defined the extensions.

So in the case of the nanobind_example, the built extension will be in $BINDIR/src/nanobind_example_ext.so, which is one level above where it will eventually go (which is nanobind_example/nanobind_example_ext.so, with the stub file nanobind_example/__init__.pyi).

If I do the following (pseudocode):

cd $BINDIR
python -m nanobind.stubgen -m src.nanobind_example_ext -r

I get a single stub named "src.pyi" written directly to the BINDIR. How can I fix up the path mapping so that I
end up with files relative to the installed package's hierarchy? I can of course use the -o switch for a single file, but I'm not sure how to do this for multiple extensions.

(I can also probably hack this together in setuptools, I was just wondering if there is a switch in stubgen that I missed that enables this.)

[wjakob]

There is also -O that changes the output directory. Does that fix your use case?

[nicholasjng]

Running from bindir with -O src still produces a src.pyi, since I now need to pass -m src.nanobind_example_ext.

cd'ing into src and running -m nanobind_example_ext -r gives me nanobind_example_ext.pyi, which I think is what I want. (I should get one .pyi file per .so, right?)

I'd argue that this is an issue because of the disparity between the source tree and the later package layout, i.e. src being mapped to root ("") in the pyproject.toml.

This however is not stubgen's fault, since Python technically allows any source tree layout, but setuptools supports only two or so natively. I'm not sure if fixing up the paths with what is in the pyproject.toml is a good solution here, since it creates a data dependency to the package it's building.

I'll see what I can do, sounds like the ball is in my court here.