Runtime error python3xy.dll not found: Missing srcs in python_repository's libpython rule for os:windows

[axbycc-mark]

🐞 bug report

The srcs attribute for this cc_library for os:windows is ["python3.dll", "libs/python{python_version_nodot}.lib"]. It is missing the version-specific binary, eg python311.dll.

rules_python/python/repositories.bzl

Lines 318 to 326 in c5c03b2

	cc_library(
	name = "libpython",
	hdrs = [":includes"],
	srcs = select({{
	"@platforms//os:windows": ["python3.dll", "libs/python{python_version_nodot}.lib"],
	"@platforms//os:macos": ["lib/libpython{python_version}.dylib"],
	"@platforms//os:linux": ["lib/libpython{python_version}.so", "lib/libpython{python_version}.so.1.0"],
	}}),
	)

This will result in a runtime error (python311.dll not found) in the following scenario.

1. User creates a cc_binary which has #include <Python.h> and which depends on the libpython above.
2. User never defines #Py_LIMITED_ABI
3. User attempts to run the cc_binary

The Python.h includes the pyconfig.h, which causes msvc to attempt linking against python3xy.dll via the#pragma comment(lib, ...)mechanism. The relevant code from the cpython project is here.
https://github.com/python/cpython/blob/d610d821fd210dce63a1132c274ffdf8acc510bc/PC/pyconfig.h.in#L315-L331

I have resolved this locally by globbing *.dll into the libpython cc_library.

A similar issue occurs if the user defines #Py_DEBUG, which causes msvc to attempt linking against the debug binary python3xy_d.dll. I did not see a way to request debug binaries using the python_repository rule but if that were enabled, I think globbing *.dll would fix that case too.

Affected Rule

python_repository

Is this a regression?

Unsure.

Description

See above.

🔬 Minimal Reproduction

See above.

🔥 Exception or Error

Runtime error python3xy.dll not found

🌍 Your Environment

Operating System:

  
Windows 10
  

Output of bazel version:

  
7.0.2
  

Rules_python version:

  
0.31.0
  

Anything else relevant?

[axbycc-mark]

Possibly related test failure

rules_python/tests/cc/current_py_cc_libs/BUILD.bazel

Lines 23 to 25 in c5c03b2

	# Mac and Windows fail with linking errors, but its not clear why; someone
	# with more C + Mac/Windows experience will have to figure it out.
	# - rickeylev@

[nicholasjng]

For the same reason as in this example, statically linking a Python extension on Windows fails when Py_LIMITED_API is defined because the unversioned libs/python3.lib is not in that list. That is fixed in #1820, depending on the feedback on that PR, I suppose I could easily integrate this case there as well.

[axbycc-mark]

Similarly, any cc_library depending on @rules_python//python/cc:current_py_cc_headers and including <Python.h> will also break when compiled with -c dbg, since this also causes Python.h to attempt to link to the python3[xy]_d.lib, which is not available.