Forums

Yet another path issue thread

Trace

2014-07-07 17:55:10,145 :Traceback (most recent call last):
2014-07-07 17:55:10,145 :  File "/bin/user_wsgi_wrapper.py", line 67, in __call__
2014-07-07 17:55:10,145 :    self.error_log_file.logger.exception("Error running WSGI application")
2014-07-07 17:55:10,145 :  File "/usr/lib/python2.7/logging/__init__.py", line 1183, in exception
2014-07-07 17:55:10,145 :    self.error(msg, *args, **kwargs)
2014-07-07 17:55:10,146 :  File "/usr/lib/python2.7/logging/__init__.py", line 1176, in error
2014-07-07 17:55:10,146 :    self._log(ERROR, msg, args, **kwargs)
2014-07-07 17:55:10,146 :  File "/usr/lib/python2.7/logging/__init__.py", line 1268, in _log
2014-07-07 17:55:10,146 :    record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
2014-07-07 17:55:10,146 :  File "/usr/lib/python2.7/logging/__init__.py", line 1242, in makeRecord
2014-07-07 17:55:10,146 :    rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
2014-07-07 17:55:10,147 :  File "/usr/lib/python2.7/logging/__init__.py", line 284, in __init__
2014-07-07 17:55:10,147 :    self.threadName = threading.current_thread().name
2014-07-07 17:55:10,147 :  File "/usr/lib/python2.7/threading.py", line 1158, in currentThread
2014-07-07 17:55:10,147 :    return _active[_get_ident()]
2014-07-07 17:55:10,147 :  File "/bin/user_wsgi_wrapper.py", line 59, in __call__
2014-07-07 17:55:10,147 :    app_iterator = self.app(environ, start_response)
2014-07-07 17:55:10,147 :  File "/home/meteorainer/.virtualenvs/django165/lib/python2.7/sitepackages/django/
core/handlers/wsgi.py", line 187, in __call__
2014-07-07 17:55:10,148 :    self.load_middleware()
2014-07-07 17:55:10,148 :  File "/home/meteorainer/.virtualenvs/django165/lib/python2.7/site-
packages/django/core/handlers/base.py", line 44, in load_middleware
2014-07-07 17:55:10,149 :    for middleware_path in settings.MIDDLEWARE_CLASSES:
2014-07-07 17:55:10,149 :  File "/home/meteorainer/.virtualenvs/django165/lib/python2.7/site-  
packages/django/conf/__init__.py", line 54, in __getattr__
2014-07-07 17:55:10,149 :    self._setup(name)
2014-07-07 17:55:10,149 :  File "/home/meteorainer/.virtualenvs/django165/lib/python2.7/site-
packages/django/conf/__init__.py", line 49, in _setup
2014-07-07 17:55:10,150 :    self._wrapped = Settings(settings_module)
2014-07-07 17:55:10,150 :  File "/home/meteorainer/.virtualenvs/django165/lib/python2.7/site-
packages/django/conf/__init__.py", line 132, in __init__
2014-07-07 17:55:10,151 :    % (self.SETTINGS_MODULE, e)
2014-07-07 17:55:10,151 :ImportError: Could not import settings 'cms.settings' (Is it on sys.path? Is there an import error in the 
settings file?): No module named settings

PA WSGI

activate_this = '/home/meteorainer/.virtualenvs/django165/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))

import os
import sys

path = '/home/meteorainer/cms'
if path not in sys.path:
    sys.path.append(path)
os.environ['DJANGO_SETTINGS_MODULE'] = 'cms.settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

App wsgi

import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cms.settings")

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

My settings.py is in /home/meteorainer/cms/cms/settings.py

  • I can create new projects and they work fine to land on the IT WORKED page.
  • I have nuked my app already, created a new one and moved stuff over. No change.
  • I have check my wsgi files numerous times. They appear to be correct.
  • I've emptied my settings an replaced with a default one (updated appnames inside the file).

I can directly interact with the settings.py:

 python -c "import settings"
 # no errors

 python
 import settings
 print settings.DEBUG
 >>>True

WHAT THE HELL DID I DO?!?!


edit

I started a new project with the same virtenv and move/renamed stuff, and can get it to load now. Something in django doesn't like when you use the same app/project name even if you kill it and start over. Is there some caching mechanism breaking this? (i killed pycache and all the .pyc in 3.3 and 2.7)

Sometimes if you name one of your django apps the same as one of the system-installed packages, python can get confused, even if you're using a virtualenv. It's because the activate_this hack still leaves system-installed packages visible...

So the short answer is that you have to make sure your own modules' names don't conflict with any system-installed ones :S

Wow. Is there a potential issue there in a shared environment? If you guys install a new battery that uses the same name I did, might something break on my site?

Well, we're getting quite conservative about what packages we'll install these days, but theoretically, yes.

We're hoping to find the time to improve our virtualenv support soon, which would fix these sorts of issues. the activate_this thing is a hack really.

I wonder if there's a way of manually fixing this problem? Maybe with a

sys.path.remove('/usr/lib/python2.7/dist-packages')

After the call to activate? Might be worth a try...

Won't that nuke my capacity to use batteries though? Not that it's hard to install them, but I figure they are already there for a reason.

Well, you would only do it inside the wsgi.py for your webapp, which is using the virtualenv modules...

cf http://virtualenv.readthedocs.org/en/latest/virtualenv.html#using-virtualenv-without-bin-python

I really like python as a language, but it seems like there a lot of caveats and different ways to set it up/activate stuff along the way. Looks like I've got some reading to do. Thanks for the link Harry!