I have different settings for different environments for my application, such as local, dev, stage, production. So, when I run my apps, say, locally, I pass the settings as the parameter to manage.py, e.g. python3 manage.py runserver 0.0.0.0:8080 --settings=myapp.settings.local, and indeed all my settings are correctly initialised, e.g. DEBUG is True as it is set in my settings file, and not False as it is in defaultsettings.py.
However, when I try to run tests with python3 manage.py test --settings=myapp.settings.local, the value of DEBUG is set to false, that is it is loaded from defaultsettings.py. Why does that happen and how can I fix this?
Make sure that in the test you import the settings like this:
from django.conf import settings
Turns out that when you run your tests, all your settings are just like they are in your settings file except for DEBUG. DEBUG is always set to False to make the set up as close to production as possible.
I ended up following this post: Detect django testing mode
import sys
TESTING = sys.argv[1:2] == ['test']
Related
I have a large flask application built inside a package called "MyApp" (exactly as shown here: http://flask.pocoo.org/docs/0.12/patterns/packages/)
According to the Flask documentation, the debug mode should enables the following features:
it activates the debugger
it activates the automatic reloader
it enables the debug mode on the Flask application.
At the beginning I've run my flask application with the following command and everything were worked fine:
export FLASK_APP=MyApp
export FLASK_DEBUG=1
flask run
Then I read about the correct way to setup a configuration system (including the debug mode).
So I created the following config.py file:
class Config(object):
DEBUG = False
...
class ProductionConfig(Config):
...
class DevelopmentConfig(Config):
DEVELOPMENT = True
DEBUG = True
...
CONFIGS = {
"development": DevelopmentConfig,
"production": ProductionConfig,
"default": DevelopmentConfig
}
And in my application __init__.py file, I wrote:
app = Flask(__name__)
config_name = os.getenv('FLASK_CONFIGURATION', 'default')
app.config.from_object(CONFIGS[config_name])
Now, to run the application I enter a new command:
export FLASK_APP=MyApp
export FLASK_CONFIGURATION=development
flask run
Unfortunately, this time the debug mode did not activated at all..
No debugger or automatic reloader has been activated.
The only thing that has been changed was that app.debug is now equals to True.
I don't get it.. It looks like the DEBUG = TRUE is not working correctly.
Do you have any idea why does it happen?
Running with the debugger is different than setting the DEBUG config. You have to do both. Running the server in debug mode sets the config automatically. Typically, you should rely on that rather than setting the config directly.
The "correct way to configure" you read about is a) just another way, not the "correct" way, and b) only sets the config, not the FLASK_DEBUG environment variable, which is what controls the debug mode for the server.
Setting the environment variable FLASK_DEBUG=1, or passing the --debug option to the flask command as of Flask 2.2, tells flask run to wrap the application with the debugger and reloader. (app.run(debug=True) does the same, but the flask run command is preferred). app.debug switches some internal behavior in the Flask app, such as passing through errors to the interactive debugger that development mode enabled.
Is settings.py the same as mysite.settings from this example here:
http://django.readthedocs.io/en/1.2.X/howto/deployment/modwsgi.html
It seems ambiguous to me if it is the same thing or not, my app has a settings.py in it but it seems like this isn't the same as mysite.settings spoken of in the docs. I do have my app running with$ python manage.py runserver just fine on centos, and even see apaches test page on the same box so i know apache is running. Was going through the doc above to try to get apache to server the django app and thats where I got confused as to what it is really asking for...
(also the apache folder didn't exist so I added that and created a django.wsgi with the code below that I think was the right thing to do).
Almost looks like I have to setup a sys.path somewhere?
https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki
When you define:
DJANGO_SETTINGS_MODULE = 'mysite.settings'
Django looks up for settings.py file in mysite folder. mysite folder has to be on your PYTHONPATH. Make sure you set your PYTHONPATH to something like:
export PYTHONPATH=/home/work/project:/home/work/project/project:$PYTHONPATH
I've set up a Django project deployed on Heroku using the Heroku Django project template. Heroku's template uses whitenoise to collect static files in a /static/ directory located on my project root.
This is great for my production environment; Heroku runs "manage.py collectstatic" each time I push new files to my server. However, it's a pain when developing locally: every time I change my static files (e.g., css), I have to manually run "python manage.py collectstatic" before seeing changes on my development server.
Is there an easy way to disable whitenoise on my local machine so that I don't have to run "python manage.py collectstatic" every time I want to see changes to local static files?
I've tried creating a separate "development_settings.py" file and removing all references to whitenoise in that file, but it doesn't work because whitenoise is still referenced in wsgi.py, which causes errors.
WhiteNoise has a setting called WHITENOISE_AUTOREFRESH for exactly this reason.
From the WhiteNoise Docs:
WHITENOISE_AUTOREFRESH: Rechecks the filesystem to see if any files have changed before responding. This is designed to be used in development where it can be convenient to pick up changes to static files without restarting the server. For both performance and security reasons, this setting should not be used in production.
The default setting of this is the value of settings.DEBUG so it should be on by default if you're running a development server.
It looks like the default Heroku template specifies an old version of WhiteNoise. If you run
pip install --upgrade whitenoise
you should find it automatically picks up changes to your static files when in development (i.e. when settings.DEBUG is True).
Although I didn't find an easy way to disable whitenoise on my development server, I did find a convenient workaround for making this whole process easier:
Add a new command alias to your .bash_profile file (or bin/activate if you are using a virtual environment for development) that both runs collectstatic and launches a server at the same time:
alias launch='python manage.py collectstatic --noinput; foreman start'
The current version of whitenoise will pick up changes in your static files automatically. But it can slow down the startup of runserver quite a bit, as it will iterate over all static files. I fixed this by disabling whitenoise in runserver. Now my wsgi.py looks like this:
import os
import sys
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "...")
application = get_wsgi_application()
# guess whether this is a runserver invocation with staticfiles
has_staticfiles = False
if 'runserver' in sys.argv:
from django.conf import settings
import inspect
if settings.DEBUG:
has_staticfiles = any(
"django/contrib/staticfiles/management/commands/runserver"
in x[1]
for x in inspect.stack())
if has_staticfiles:
print('runserver with staticfiles detected, skipping whitenoise')
else:
# Do not use whitenoise with runserver, as it's slow
from whitenoise.django import DjangoWhiteNoise
application = DjangoWhiteNoise(application)
This does not work for me
$> cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"
django 1.7rc3
celery 3.1.13
python 2.7
I attempt to run
celery worker -A <project_name>
and I get
django.core.exceptions.AppRegistryNotReady: Models aren't loaded yet.
The runserver command works fine so I don't think it has to do with my settings?
python manage.py runserver 0.0.0.0:8080
I've double checked celery.py and confirm it has the correct values for the following lines:
# set the default Django settings module for the 'celery' program.
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')
app = Celery('proj')
# Using a string here means the worker will not have to
# pickle the object when using Windows.
app.config_from_object('django.conf:settings')
Is there something else i should be doing?
Django 1.7 now requires a different initialization for standalone scripts. When running outside the manage.py context, you now need to include:
import django
django.setup()
Try adding it before the app = Celery('proj') in your script.
I found out that the reason this was failing is because i had this in one of my tasks.py
CURRENT_DOMAIN = Site.objects.get_current().domain
I got side steped this for now with
CURRENT_DOMAIN = lambda: Site.objects.get_current().domain
currently waiting to see if anyone on github cares to offer a better recommendation.
https://github.com/celery/celery/issues/2227
will update if i get one. If not will probably just do a helper function that lazy returns the value i want.
update
at the suggestion of celery author, I've refactored my code so I don't make that call at the module level.
He's also addressed the issue by making sure django.setup() is called before importing task modules
https://github.com/celery/celery/issues/2227
I'm seeing the same issue however only with:
CELERYBEAT_SCHEDULER='djcelery.schedulers.DatabaseScheduler'
Do you have this enabled? If I run it with the default celery scheduler it loads fine. But can't get it to load with the Django scheduler.
I'm developing a flask.app that uses web socket functionality and installed flask-socket to provide that. So the flask-socket developer recommends gunicorn as web server. My question is now how to connect the remove debugger of pycharm with gunicorn to intercept the execution with breakpoints.
Settings > Project Settings > Python Debugger
There's an option in there to enable "gevent compatible debugging".
Then, go into your debugger settings (shortcut is through the toolbar, click the dropdown near the play/debug icons and select "Edit Configurations"
Set the "Script" to your virtualenv's isntallation of gunicorn, something like:
/Users/iandouglas/.virtualenvs/defaultenv/bin/gunicorn
Set the "Script Parameters" to something like
-b 192.168.1.1:9000 app:yourappname (assuming your primary starting script is called app.py and you're refering to it as 'yourappname'
the "Working directory" will be automatically set otherwise set it to wherever your code lives: /Users/iandouglas/PycharmProjects/MyExampleApp
I have a separate config file for my gunicorn settings, which specifies a host/port but I still had to specify the -b 0.0.0.0:5001 parameter to force gunicorn to bind to all IPs on my machine on port 5001.
p.s.
One important step is to add this envvar as pointed out here
PYDEVD_USE_CYTHON=NO
My case for PyCharm 2018.1.3 Professional:
Go to run/debug configurations
creating-and-editing-run-debug-configurations
Choose new "Python" config
Script path: your_path_to_/venv/bin/gunicorn
Parameters(for my case): -b :5001 --access-logfile - --error-logfile - "run:create_application()"
Python interpreter: your venv python version for project
Working directory: path to your project
Save and press DEBUG (Shift+F9)
be happy!
I was trying to debug on Pycharm 2020.2.1 and the break points weren't correctly working even though the Gevent compatible debugging was enabled. It turned out that I had to disable Cython for my run configuration via setting the environment variable as described here to make it work.
PYDEVD_USE_CYTHON=NO
edit your flask launch python file
$ vim manage.py
remove debug option setting
from web import app
import sys
if __name__ == '__main__':
# app.run(host='0.0.0.0', port=app.config["PORT"], debug=app.config["DEBUG"])
app.run(host='0.0.0.0', port=9998, debug=False)