I'm seeing this issue in a third-party package that uses CMake and Make based build systems rather then setuptools (it's a mostly C library which additionally provides some python wrappers). Those build systems can normally parse a python installation with the standard directory structure to find the library and headers, but fail on a venv. I can bring this up with the package developers, but I don't see any downsides to linking the headers/libraries in the venv to make it easy to use.

Regarding the comment that venv's are primarily for runtime, I didn't see anything in PEP 405 that supports that statement. And in any case, even for runtime environments, installing a python package from a source distribution is valid, right? So shouldn't the venv support building extensions?

Again, I agree that third party packages that provide python wrappers should probably use standard tools (i.e., setuptools) to build the python C extensions, but I fail to see the downsides to including links to the headers/libraries in the venv for ease of use.