If your Python 3 is the system Python, then LD_RUN_PATH shouldn’t be needed.
I presume you mean pyvenv and not pyenv as pyenv is a tool for installing whole Python installations, not just virtual environment. The preference is to use virtualenv over pyvenv as know virtualenv always works. Graham > On 20 Oct 2016, at 12:03 PM, Shanti Suresh <[email protected]> wrote: > > Hi Graham, > > Thank you. > > I tried with both pyenv as well as virtualenv and both times, it is the > "encodings" module. > > Thank God, it is not 'django' anymore. I will try recompiling. The Python > binaries include: > /usr/bin/python2.7 > /usr/bin/python2.7-config > /usr/bin/python3.4 > /usr/bin/python3.4m > /usr/bin/python3.4m-x86_64-config > > -Shanti > > On Wednesday, October 19, 2016 at 8:51:41 PM UTC-4, Graham Dumpleton wrote: > Do you have multiple Python 3 versions installed on your system? > > It may be picking up wrong shared library at run time: > > > http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-shared-library > > <http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-shared-library> > > The solution to that if it is the case, is to work out where the shared > library is for the main Python installation of version you want to use is, > and set the LD_RUN_PATH environment at the time of compilation to where that > directory is. For example, if Python 3 you want to use is under /usr/local, > use: > > make distclean > ./configure --with-apxs=/usr/bin/apxs --with-python=/usr/local/bin/python3 > LD_RUN_PATH=/usr/local/lib make > sudo make install > > BTW, are you using Anaconda Python? > > Did you use virtualenv or pyvenv to create the Python virtual environment. > > The pyvenv approach is broken for when embedding Python. I had a workaround > for it, but is possible some recent changes I made so that Anaconda Python > would work has upset that. Or the workaround will not work for Anaconda > Python anyway. > > Graham > >> On 20 Oct 2016, at 11:44 AM, Shanti Suresh <shantis...@ <>gmail.com >> <http://gmail.com/>> wrote: >> >> Hi Graham, >> >> Thanks so much for your response. >> >> With those changes, I get: >> >> Fatal Python error: Py_Initialize: Unable to get the locale encoding >> ImportError: No module named 'encodings' >> >> I also removed "lang='en_US.UTF-8' locale='en_US.UTF-8’" just for fun, but I >> still get the error about encodings. >> I don't have an "encodings" module in my Django project. >> >> Thanks again, >> >> -Shanti >> >> On Wednesday, October 19, 2016 at 8:15:32 PM UTC-4, Graham Dumpleton wrote: >> >>> On 20 Oct 2016, at 10:56 AM, Shanti Suresh <[email protected] <>> wrote: >>> >>> Greetings, >>> >>> Thank you for your help, in advance! It has been a frustrating day. >>> >>> I have a virtualenv configured with Python3.4.3 on RedHat release 7.2. >>> >>> I configured mod_wsgi-3.4 as: >>> ./configure --with-apxs=/usr/bin/apxs >>> --with-python=/usr/local/dev/env/bin/python3 >> >> Are you using your own Python installation or that from the Software >> Collections Library? I am presuming it is your own rather than SCL as SCL >> latest is Python 3.4.2. Just want to make sure. >> >> Anyway, even if you intend to use a virtual environment, it is often better >> to still compile mod_wsgi against the main Python installation. This will >> avoid complications if later want to have multiple daemon process groups >> using different Python virtual environments. >> >> So would recommend doing a: >> >> make distclean >> >> then rerun configure but this time use the python3 from where it was >> originally installed. >> >>> make >>> sudo cp .libs/mod_wsgi.so /etc/httpd/modules/ >>> >>> -- >>> My wsgi.py file reads: >>> import os >>> os.environ.setdefault("DJANGO_SETTINGS_MODULE", >>> "knack_djangoapp.settings_temp") >>> >>> from django.core.wsgi import get_wsgi_application >>> application = get_wsgi_application() >>> -- >>> -- >>> In httpd.conf, I have: >> >> Because best practice is to always use daemon mode, I would recommend adding >> outside of VirtualHost, usually just after where the wsgi_module is loaded: >> >> WSGIRestrictEmbedded On >> >> This will prevent Python being initialised in the Apache child worker >> processes and will only be initialised in daemon processes. >> >> If your configuration isn’t quite right and for some reason it tries to run >> stuff in embedded mode, you will now get an error saying something is wrong. >> Thus helps to avoid mistakes. >> >>> <VirtualHost *:81> >>> DocumentRoot /var/www/html/dev >>> ServerName dev.domain.edu <http://dev.domain.edu/> >>> WSGIDaemonProcess dev >>> python-path=/usr/local//dev/djangoapp:/usr/local/dev/env/lib/python3.4/site-packages/ >>> lang='en_US.UTF-8' locale='en_US.UTF-8’ >> >> Recommend using: >> >> WSGIDaemonProcess dev python-home=/usr/local/dev/env >> python-path=/usr/local//dev/djangoapp lang='en_US.UTF-8' locale='en_US.UTF-8’ >> WSGIApplicationGroup %{GLOBAL} >> >> The important bit here is using python-home to set the location of the >> virtual environment. This will be what sys.prefix is set to for Python when >> run under the virtual environment. Don’t set up the virtual environment >> using site-packages in python-path. >> >> The WSGIApplicationGroup is also good practice if only have one application >> per daemon process group, as is recommended, as avoids problems with some >> third party C extensions for Python that will not work in Python sub >> interpreters. >> >>> WSGIProcessGroup dev >> >> This is actually redundant as as process-group option on WSGIScriptAlias. >> >>> WSGIScriptAlias / /usr/local/dev/djangoapp/wsgi.py process-group=dev >>> <Directory /usr/local/dev/djangoapp/> >>> <Files wsgi.py> >>> Require all granted >>> </Files> >>> </Directory> >>> </VirtualHost> >>> -- >>> >>> -- >>> In my vrtualenv: >>> pip freeze gives: >>> Django==1.8.15 >>> mod-wsgi==4.5.7 >>> -- >>> >>> Upon starting httpd as /sbin/service httpd start, I get: >>> ...Adding '/usr/local/dev/env/lib/python3.4/site-packages/' to path >>> ...Target WSGI script '/usr/local/dev/djangoapp/wsgi.py' cannot be loaded >>> as Python module. >>> ...Exception occurred processing WSGI script >>> '/usr/local/dev/djangoapp/wsgi.py' >>> ...from django.core.wsgi import get_wsgi_application >>> ...ImportError: No module named 'django' >>> >>> I greatly appreciate any and all help. I am at my wits' end. mod_wsgi >>> seems to be using the system python interpreter. It is not using the >>> virtualenv appropriately. >> >> So those are things I would recommend, but how you had it should still have >> worked. >> >> What I would suggest is temporarily replace the wsgi.py file with test >> script in: >> >> >> http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-installation-in-use >> >> <http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-installation-in-use> >> >> This will log some details about the Python virtual environment being used. >> You can then verify is the virtual environment you expect it to be. >> >> Other things to check are that the user that Apache run as has access to >> everything in the virtual environment. That would usually mean access to >> ‘others’ for files and directories. >> >> The only other thing can think of is that SELinux is causing problems, but >> doubt that as it wouldn’t be able to access the wsgi.py even if that was the >> case. >> >> So try that test WSGI script to see if correct virtual environment. Also in >> Python from command line do: >> >> import django >> print(django.__file__) >> >> and see if where Django actually is, corresponds to where you expect it to >> and where mod_wsgi is looking. Modify the test script to print out the value >> of sys.path to see if the directory is in the module search path if >> necessary. >> >> Graham >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to modwsgi+u...@ <>googlegroups.com <http://googlegroups.com/>. >> To post to this group, send email to mod...@ <>googlegroups.com >> <http://googlegroups.com/>. >> Visit this group at https://groups.google.com/group/modwsgi >> <https://groups.google.com/group/modwsgi>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
