The libpython.a or libpython.so objects are not copied/linked in new virtual environments when created with venv.

Can you please provide more information about this behavior?

A typical python installation includes libpython libraries that C extensions can link to. Creating virtual environments with venv normally creates a replica of a python installation directory, including all the built in python modules. However, it doesn't seem to copy over the libpython libraries, so C extensions built with a venv activated can't seem to find the libpython (.so, .a, .dll) file to link against.

For example, compare the installation directory of python with the venv directory. The libpython .so/.a/.dll files are missing in the venv

Also, at least on windows, the C-API header files are also missing from the venv

This is not a bug - venvs are primarily *run*-time (as opposed to development-time) environments, into which you install pre-built Python packages (including ones with C extensions). Can you give a specific example where creating a venv and installing packages into it leads to a problem due to libpython.XXX being unavailable, with a series of steps to reproduce? If not, this issue will need to be closed.

I agree with Vinay. venvs don't contain copies of libpython or header files by design. setuptools will pcik them up from the main installation.

If you have any issues with compiling C extensions, please report them with setuptools at https://github.com/pypa/setuptools/

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.

This sounds like a bug in CMake or Make. Are you using any CMake plugins or autoconf/automake macros? It's very well possible that the author of these extension made a wrong assumption or the extension was written before venvs were introduced.

A venv does *not* create a replica of a python installation directory. Files shared with the main Python installation are not copied nor linked. This goes for the standard library, as well as the libraries and headers.
(*Executables* are an exception; they're copied, since a venv needs them on the PATH.)

Copies would take up unnecessary space, and not all operating systems support symbolic links (and we don't want another platform-specific difference), so the shared files are only referenced using pyvenv.cfg


If you point to the macros you're using, I can take a look at how they could be improved.