Support Windows .pyd targets for Python Wheel Packaging

[Andrewyx]

Hello! This PR provides extended support for projects which use pybind11_bazel to produce Python wheels.

As a developer on PyScreenReader, it was discovered that the current implementation of pybind11_bazel and its method of copying .so pybind_extension to .pyd file formats using copy_file does not work for the rules_python py_wheel rule. The reason for this appears to be that the generated .pyd file is not a true target which can be referred to by the py_wheel rule, or the dependency resolution graph struggles with this generated file strategy. This seems to have resulted in no one in the community developing Windows-based Python packages using pybind11 and Bazel.

Regardless, the solution here is to use a similar strategy mentioned in #74 which used a genrule to create a valid target for the aliasing.

[Mizux]

What's about this instead ?
https://github.com/Mizux/bazel-pybind11/blob/main/patches/pybind11_bazel.patch

[Andrewyx]

@Mizux Let me try this once I get home, I believe merging in that patch should work. However, I don't think the py_deps param is necessary since it implies that the pybinded extension itself requires some sort of Python dep (which is originally written in C++).

[Mizux]

IIRC It could be needed when your C++ pybind11 bind some methods and you want numpy support etc...

[Andrewyx]

After some testing and fiddling, it looks like that patch does not work. The problem appears to be due to the py_library part of the macro:

    native.py_library(
        name = name,
        data = select({
            "@platforms//os:windows": [":" + name + ".pyd"],
            "//conditions:default": [":" + name + ".so"],
        }),
        deps = py_deps,
        visibility = visibility,
    )

Specifically, the data is not triggering the genrule to create the .pyd file, and in the finished wheel, the .pyd is not present (i.e. build of the wheel target succeeds, but the data itself is missing).

I like the idea of wrapping the macro using the py_library rule, but I think Bazel/pybind11 enforces strict semantic calls to particular data names to add them to the dependency tree (e.g. name + .so or name_ + .pyd). Using the exact names from the native cc_binary rules seems to cause the shared libs to generate. I suspect this is also where this stack overflow issue arises from. This also explains why using native.alias works, since it is directly calling the shared lib targets.

[Mizux]

@Andrewyx after doing few tests on a windows laptop it seems that:

• I was able to modify the examples/basic to reproduce this? error...
  see: https://github.com/Mizux/pybind11_bazel/actions/runs/18137865310/job/51621163663
• you only need to replace "@platforms//os:windows": [":" + name + ".pyd"] by the alias target name instead
  see: 5154c10
• I prefer to keep the copy_file() function instead on relaying on the system cp cmd, feel it more hermetic, robust and "bazel-ish" implem imho.

=> leading to this PR:

• Fix py_wheel support on windows #120 which should replace this PR...

[Andrewyx]

Looks good and appears to be working on my end too! I'll go ahead and close this issue now. Thanks for the help! 😄

[Mizux]

Looks good and appears to be working on my end too! I'll go ahead and close this issue now. Thanks for the help! 😄

sorry for the ping, just to say I'm not done to play with .pyd windows support
You may track the issue #124 (WiP) where i'll try to summarize what's work, what's not, my investigation etc... feel free to participate if you want...