pip install mod_wsgi fails in virtualenv

Question

I'm trying to install mod_wsgi using pip in python 2.7.10 on mac os 10.12 inside a virtualenv. I intend to use it in a a Django 1.10.3. When I run "pip install mod_wsgi" I get the following output:

Collecting mod_wsgi
Using cached mod_wsgi-4.5.7.tar.gz
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/private/var/folders/sf/kdqqs98d06326180mss7hggh0000gn/T/pip-build-hgA7s1/mod-wsgi/setup.py", line 247, in <module>
    APR_INCLUDES = get_apr_includes().split()
  File "/private/var/folders/sf/kdqqs98d06326180mss7hggh0000gn/T/pip-build-hgA7s1/mod-wsgi/setup.py", line 219, in get_apr_includes
    stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1335, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/sf/kdqqs98d06326180mss7hggh0000gn/T/pip-build-hgA7s1/mod-wsgi/

I'm new to virtualenv so it might be that I'm just missing something with how to set that up. I've tried upgrading pip, reinstalling setuptools and ez_setup via pip.

Answer 1

There are two problems with installing mod_wsgi on MacOS X Sierra.

The first problem is that Apple has made the default Apache installation they provide entirely unusable when it comes to being able to install third party Apache modules. This builds on top of obstacles they already had in prior MacOS X versions which meant you had to jump through hoops to get it working.

The issue in this case is that Apple has removed the apr-1-config and apu-1-config programs from the Xcode distribution. This means that apxs will fail when certain types of queries are made about the Apache configuration that exists. This is information that is needed to build third party modules for Apache. Without knowing where header files are installed, builds of Apache modules will fail.

Given Apple's history of breaking the ability to install additional Apache modules in every OS update, and never fixing it for the life of the OS, thus requiring workarounds, it is unlikely once again that they will fix this problem.

In other forums one suggestion to get around the problem is to install APR and APU packages with brew and then symlink the apr-1-config and apu-1-config programs from those into the location apxs is looking. This to me looks error prone as it seems that modules then might be compiled against brew header files and these may not match the library version for those provided by the operating system Apache installation. That could result in crashes.

The only guaranteed solution is therefore not to use the Apache installation supplied with the operating system.

So one option may be to use brew to install Apache and use the brew installation of Apache (not just APR and APU from brew).

Another option if using pip install mod_wsgi method, is to first use the pip installable Apache provided for mod_wsgi.

pip install -vvv mod_wsgi-httpd

Using this should only be done where have no choice and you should always use the system Apache if you can. Right now we don't seem to have a choice.

This will install Apache into the Python installation or virtual environment. It will take a bit of time as it is going to compile/install APR/APU/Apache and possibly other required libraries as well. Am using -vvv so you can see it doing the compilation else you might think it has hung.

Once that is done then run pip install mod_wsgi.

This is only useful if using mod_wsgi-express. You can't use this if then want to use the compiled mod_wsgi with the operating system Apache as the module built this way will be incompatible with the operating system Apache.

The second problem is that MacOS X Sierra changed operating system APIs for getting process task information. This will mean mod_wsgi 4.5.7 and earlier will fail to compile anyway. There is a fix coming in mod_wsgi 4.5.8, or you can use code from the mod_wsgi github repository until 4.5.8 is released if need to.

---

UPDATE 1

Managed to include a hack in setup.py for when doing pip install mod_wsgi. This will also be in mod_wsgi 4.5.8. It means you can still use the system Apache and don't need to install a separate one such as by using pip install mod_wsgi-httpd. This will not solve similar problems with for configure/make method for installing mod_wsgi.