The only other can think of is that the main Python installation was patched/upgraded between when virtual environment was created and when it was used. This can cause some strange problems to occur and necessitates recreation of the virtual environment.
Graham > On 20 Oct 2016, at 12:06 PM, Graham Dumpleton <[email protected]> > wrote: > > 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] >> <mailto:[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.
