tl;dr: Use WSGIDaemonProcess python-home=…. The alternatives using either WSGIPythonPath or WSGIDaemonProcess python-path=… (with -path instead of -home!) are no longer recommended.
The old and the new way
As mentioned by @kaykae, WSGIPythonPath cannot be used in a VirtualHost context but WSGIDaemonProcess python-path=… is the equivalent. However while this can still work, it is no longer the recommended way to set up Apache mod_wsgi with virtual Python environments:
Note that prior practice was that these ways of setting the Python module search path [namely WSGIDaemonProcess …python-path=… and WSGIPythonPath] were used to specify the location of the Python virtual environment. Specifically, they were used to add the site-packages directory of the Python virtual environment. You should not do that.
The better way to specify the location of the Python virtual environment is using the python-home option of the WSGIDaemonProcess directive for daemon mode, or the WSGIPythonHome directive for embedded mode. These ways of specifying the Python virtual environment have been available since mod_wsgi 3.0 and Linux distributions have not shipped such an old version of mod_wsgi for quite some time. If you are using the older way, please update your configurations.
(Source: WSGI Docs: User Guides: Virtual Environments)
How to do it the new way
The fact that you try to configure mod_wsgi inside a VirtualHost context shows you use the "daemon mode" configuration version. According to the quote above, the recommended way to include your virtualenv environment into your Python path would then be a section like this in your VirtualHost section (though it can also be defined outside, as it can be referenced with the myapp1 identifier for the daemon process group that you choose):
<IfModule mod_wsgi.c>
WSGIDaemonProcess myapp1 user=user1 group=group1 threads=5
python-home=/path/to/project/venv
</IfModule>
Note that /path/to/project/venv is the base path of your virtualenv environment. It would be a subdirectory venv in the directory where you called virtualenv venv to create it.
Also note that you can add other paths to your Python path to make your import statements work for packages not managed via PIP or similar. For example you can add python-path=/path/to/project. Just don't use that mechanism to tell wsgi about the whole virtualenv setup – for that they introduced python-home.