clarifications about mod_wsgi and virtual environments

[JBPressac]

Hello,

I am using mod_wsgi through the libapache2-mod-wsgi Debian package and Django installed in a pipenv virtual environment (using the same Python version than the version used by the system, but installed with pyenv). Despite the fact that the Debian package was certainly not compiled with the Python of the pipenv virtual environment, Django could run.

So, I do not understand why, the documentation says:

The problem in trying to force mod_wsgi to use a different Python installation than what it was compiled for, even where it is the same Python version, is that the Python installation may itself not have been compiled with the same options. This is especially a problem when it comes to issues around how Python stores Unicode characters in memory.

[GrahamDumpleton]

Installing Python with different configurations can technically result in Python runtime binaries which are not binary compatible when it comes to loading C extensions.

As noted, this especially used to be a problem around unicode strings as it was possible to configure and build Python to use either 16 bit to 32 bit native unicode characters. This resulted in different versions of functions being used and it was not possible to dynamically link a C extension compiled with a different unicode characters width.

In the case of unicode characters this should not be an issue in modern Python versions as a switch was made to dynamically adjust to unicode characters code width in the Python code instead.

So this whole issue may not be as problematic as it used to be, but I can't rule out that there aren't other configuration options for installing Python that could result in a runtime which is not binary compatible with a separate Python installation. So it is a precautionary warning.

FWIW, I talk a bit about this issue in this old blog post.

• http://blog.dscpl.com.au/2015/06/installing-custom-python-version-into.html

Do also note that pyenv especially has had a history of ignoring conventional wisdom around best way to configure Python when installed. For example, it would not even enable the creation of a shared library for Python, meaning a pyenv generated Python installation could not be used in an embedded manner inside something like Apache/mod_wsgi.

Another case where mixing Python installations could be an issue would be trying to use Anaconda Python artifacts with a standard PSF distribution.

[JBPressac]

Thank you for this answer.