2016-04-26 20 views
5

Sto cercando di utilizzare Foreman/Honcho per gestire la mia applicazione Django basata su Procfile. Quando avvio l'app, visualizzo il normale python manage.py runserver, tutto funziona correttamente. Tuttavia, quando inizio l'applicazione tramite honcho start o foreman start web, sto ricevendo questo errore:Django - Foreman non trova i modelli installati

11:59:31 system | web.1 started (pid=27959) 
11:59:31 web.1 | [2016-04-26 11:59:31 -0700] [27959] [INFO] Starting gunicorn 19.4.5 
11:59:31 web.1 | [2016-04-26 11:59:31 -0700] [27959] [INFO] Listening at: http://0.0.0.0:5000 (27959) 
11:59:31 web.1 | [2016-04-26 11:59:31 -0700] [27959] [INFO] Using worker: sync 
11:59:31 web.1 | [2016-04-26 11:59:31 -0700] [27962] [INFO] Booting worker with pid: 27962 
11:59:31 web.1 | [2016-04-26 18:59:31 +0000] [27962] [ERROR] Exception in worker process: 
11:59:31 web.1 | Traceback (most recent call last): 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/gunicorn/arbiter.py", line 515, in spawn_worker 
11:59:31 web.1 |  worker.init_process() 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/gunicorn/workers/base.py", line 122, in init_process 
11:59:31 web.1 |  self.load_wsgi() 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/gunicorn/workers/base.py", line 130, in load_wsgi 
11:59:31 web.1 |  self.wsgi = self.app.wsgi() 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/gunicorn/app/base.py", line 67, in wsgi 
11:59:31 web.1 |  self.callable = self.load() 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/gunicorn/app/wsgiapp.py", line 65, in load 
11:59:31 web.1 |  return self.load_wsgiapp() 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp 
11:59:31 web.1 |  return util.import_app(self.app_uri) 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/gunicorn/util.py", line 357, in import_app 
11:59:31 web.1 |  __import__(module) 
11:59:31 web.1 | File "../wsgi.py", line 17, in <module> 
11:59:31 web.1 |  application = get_wsgi_application() 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/django/core/wsgi.py", line 13, in get_wsgi_application 
11:59:31 web.1 |  django.setup() 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/django/__init__.py", line 18, in setup 
11:59:31 web.1 |  apps.populate(settings.INSTALLED_APPS) 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/django/apps/registry.py", line 85, in populate 
11:59:31 web.1 |  app_config = AppConfig.create(entry) 
11:59:31 web.1 | File "/Library/Python/2.7/site-packages/django/apps/config.py", line 90, in create 
11:59:31 web.1 |  module = import_module(entry) 
11:59:31 web.1 | File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py", line 37, in import_module 
11:59:31 web.1 |  __import__(name) 
11:59:31 web.1 | ImportError: No module named django_messages 
11:59:31 web.1 | [2016-04-26 18:59:31 +0000] [27962] [INFO] Worker exiting (pid: 27962) 
11:59:31 web.1 | [2016-04-26 11:59:31 -0700] [27959] [INFO] Shutting down: Master 
11:59:31 web.1 | [2016-04-26 11:59:31 -0700] [27959] [INFO] Reason: Worker failed to boot. 
11:59:31 system | web.1 stopped (rc=3) 

Questo è con il tentativo di installare il modulo django-message. Ho gli stessi problemi con gli altri moduli. Sto anche incontrando lo stesso problema con django-webpack-loader. Dovrei anche menzionare che sto ricevendo l'errore sia all'interno di un virtualenv che quando è disattivato.

Ecco il comando per l'installazione django-messaggi:

$> pip install django-messages 
Requirement already satisfied (use --upgrade to upgrade): django-messages in ./lib/python2.7/site-packages 

applicazioni installate;

INSTALLED_APPS = (
    'django.contrib.admin', 
    'django.contrib.auth', 
    'django.contrib.contenttypes', 
    'django.contrib.sessions', 
    'django.contrib.messages', 
    'django.contrib.staticfiles', 
    'my_app', 
    'django_messages', 
) 

io non sono sicuro di quello che altre informazioni posso fornire per la risoluzione, ma la questione di fondo è applicazioni come faccio a installati per lavorare con caposquadra/honcho?

+0

Sembra che l'istanza di Python tra la console e 'honcho' è diverso. Usi virtualenv? –

+0

Sì. Sto ricevendo lo stesso errore sia all'interno del virtualenv che con esso disattivato. – dperconti

+0

Vedo. Quindi, sembra che il 'honcho' usi il sistema Python. Nel frattempo, si installa la libreria su quella virtuale. –

risposta

3

Honcho e Foreman non utilizzano l'eseguibile Python e le librerie libere dal tuo virtualenv e, anche se non hai incluso il tuo Procoble Honcho, la semplice chiamata python utilizzerà l'eseguibile e le librerie dell'intero sistema.

Sfortunatamente, non è possibile chiamare semplicemente /path/to/virtualenv/bin/activate come parte del Procfile, perché Honcho si chiude quando uno dei sottoprocessi termina, come discusso in this Github issue thread. Tuttavia, è possibile eseguire questo script e lo script python in una subshell utilizzando l'operatore && loro concatenare:

web: source venv/bin/activate && python manage.py 

In alternativa, si potrebbe avere più fortuna modificare la vostra wsgi.py involucro per tirare in modo esplicito nelle biblioteche del virtualenv prima dell'importazione l'applicazione Django:

# Activate your virtual env 
activate_env=os.path.expanduser("/path/to/virtualenv/bin/activate_this.py") 
execfile(activate_env, dict(__file__=activate_env)) 

Questi deve essere eseguito prima di importare tutti i moduli (diversi os) per garantire che l'applicazione legge le librerie del sito corretti.

Infine, lo stesso Honcho supporta l'uso dei file .env insieme al Procfile che imposta l'ambiente in cui vengono eseguiti i processi. Il formato di questo file è lo stesso di qualsiasi script bash. È possibile utilizzare il file .env per impostare PYTHONPATH e PYTHONHOME in modo che punti alle librerie nel proprio Virtualenv, quindi specificare l'interprete Python esplicito all'interno di Virtualenv dal Procfile.

.env file

PYTHONHOME=/path/to/virtualenv/lib/python2.7 
PYTHONHOME= 
+1

La modifica 'wsgi.py' lo ha risolto. Molte grazie! – dperconti

Problemi correlati