All my apps are in apps folder
I also added sys.path.insert(0, os.path.join(BASE_DIR, "apps"))
in settings.py
my project structure as below:
But when I simply create and run a default Django Server in Pycharm (2019.1)
It returned an error
... 'apps' is not a package
My project runs perfectly in pipenv shell; python manage.py runserver
Can anyone help me, please?
I figure out it's due to the Content Root setting
My Git root is dwhnt but my Django root is dwhnt/proj
After deleting the old Content Root and set it with as below it works
Related
I have implemented mypy in my django rest framework but I am getting errors ModuleNotFoundError: No module named 'config' while running mypy.Is there any wrong with my django_settings_module in my mypy.ini file ?
I used to run my project with the command python manage.py runserver --settings=config.settings.development which was working fine but while configuring this setting in the mypy it is giving me error. What I might be doing wrong ?
Any help would be appreciated.
mypy.ini
[mypy]
plugins =
mypy_django_plugin.main,
mypy_drf_plugin.main
ignore_missing_imports = True
warn_unused_ignores = True
strict_optional = True
check_untyped_defs = True
follow_imports = silent
show_column_numbers = True
[mypy.plugins.django-stubs]
export PYTHONPATH=$PYTHONPATH:D:\DjangoProjects\project\config
django_settings_module = config.settings.development
settings directory
/project
/config
__init__.py
urls.py
wsgi.py
/settings
__init__.py
base.py
development.py
wsgi.py
app_path = os.path.abspath(
os.path.join(os.path.dirname(os.path.abspath(__file__)), os.pardir)
)
sys.path.append(os.path.join(app_path, "project"))
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings')
application = get_wsgi_application()
If anybody happens to run into this and was as confused as I am, here is what I did to make sure the mypy django plugin works.
I indeed had to add my project root to PYTHONPATYH, such that the plugin will be able to find your project. But let me clarify. In windows, you can search for 'environment variables' and create an environment variable named PYTHONPATH there, or edit the one that is already there with an added path.
I had been banging my head against the walls for a couple hours, because I didn't know how to properly set the PYTHONPATH. When you add this variable, make sure it is the full path, and that the folder you're specifying is the folder that includes manage.py
For me, that was C:\Users\...\myproject (without the trailing slash).
I hope that works and that I can save someone from wasting hours of their life like I did.
Adding my two cents here - in my case I was running a system-wide mypy instead of the one from virtualenv:
Even though I was in the virtualenv
(env) ➜ project git:(develop) ✗ which python
/Users/Kramer/Documents/projects/example/env/bin/python
Mypy was not aliased:
(env) ➜ project git:(develop) ✗ which mypy
/usr/local/bin/mypy
The solution was to either:
run mypy directly
(env) ➜ project git:(develop) ✗ ../env/bin/mypy .
ensure that you have all the dependencies installed in the system-wide python installation
I've followed the official Heroku docs on Django and Static Assets; I've installed dj-static and added it to my requirements.txt file, properly configured all the variables in my settings.py file:
STATIC_ROOT = os.path.join(CONFIG_ROOT, 'served/static/')
STATIC_URL = '/static/'
STATICFILES_DIRS = (
os.path.join(CONFIG_ROOT, 'static'),
)
And this is what my wsgi.py looks like:
import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_django_project.settings")
from django.core.wsgi import get_wsgi_application
from dj_static import Cling
application = Cling(get_wsgi_application())
The contents of Procfile:
web: gunicorn --bind 0.0.0.0:$PORT my_django_project.wsgi:application
In the docs, it says that "collectstatic is run automatically when it is configured properly." But when I navigate to my site there's clearly no css.
I've tried debugging using heroku run, but that just copies the static files as expected.
I've noticed that when I include the collectstatic command in my Procfile, i.e.
web: python my_django_project/manage.py collectstatic --noinput ; gunicorn -b 0.0.0.0:$PORT my_django_project.wsgi:application
...that works as expected, and the static files are served.
However what's strange about that is when I run heroku run bash and look inside the directory that STATIC_ROOT is pointing to, there's nothing there! In fact, the entire served/ directory is missing, and yet, the static files are still being served!
I'd still like to know why isn't collectstatic being run automatically though -- like mentioned in the docs -- when I deploy my Django app to Heroku.
It looks like you might be using a specific settings module for Heroku/production. Further, you've set the environment variable DJANGO_SETTINGS_MODULE to point to this settings module (and that way, when the app runs, Django knows to use that one and not, say, your default/development one). Finally, you've probably configured static asset settings in Heroku/production settings module (perhaps, STATIC_ROOT).
Okay, so if this is all correct, then here is the issue: heroku environment variables are only set at serve-time, not at compile-time. This is important because collectstatic is a compile-time operation for Heroku. (Heroku goes through 2 stages when you push: 1) compiling, which involves setting the application up (collectstatic, syncdb, etc) 2) serving, the normal operation of your application).
So, essentially, you've done everything correctly, but Heroku hasn't exposed your environment variables, including your specification of a different settings module, to collectstatic.
To have your environment variables set to compile-time, enable Heroku's user-env-compile lab feature like this:
heroku labs:enable user-env-compile
I think this is a silly thing to do by default, and would be interested in hearing why Heroku thought it was a good idea.
Have you tried adding the user_env_compile setting to your heroku config?
heroku labs:enable user-env-compile
With that enabled collectstatic should be run whenever you deploy to heroku automatically.
I am using the heroku python buildpack with dokku, and collectstatic was not being run because it had no execute permission. They fixed that in a recent commit (Dec 13, 2013), so it should work now.
I am neewbie with django and I am stuck trying to deploy my project on the server ( a shared Dreamhost server). I have followed the tutorials I found but it doesnt work. My project structure is:
/usr/mydomain.com
- public
* media
* static
- project
* __init__.py
* manage.py
* settings.py
* urls.py
* views.py
- tmp
- django-setup.py
- manage.py
- passenger_wsgi.py
- passenger_wsgi.pyc
It only works on my domain.com/admin, but I have a simple 'hello world' view to try but it isnt showing. I get only an HTTP 404 when I access my domain...
EDIT
I have installed Python 2.7 and Django 1.5 . Now I get a 500 Internal Server Error.
This is how I do it, with Django 1.5, on DreamHost:
A virtualenv dedicated to my project is in ~/virtualenv/myproject
My Django project is in ~/projects/myproject, with setup:
The database file is in the project root, named sqlite3.db
STATIC_ROOT is set to os.path.join(os.path.abspath(os.path.dirname(__file__)), '..', 'static'), that is, the static directory in the project root.
When the static files are updated in the project, I have to run python manage.py collectstatic
I have per-environment settings in ~/projects/myproject/myproject, named prod_settings.py, beta_settings.py, and so on.
My site is in ~/sites/www.myproject.com, the layout inside:
myproject -- symlink to the Django project
sqlite3.db -- symlink to the database file in the Django project
public/static -- symlink to the STATIC_ROOT defined in the Django project
tmp/restart.txt -- touch this file to have Passenger reload the site settings
passenger_wsgi.py -- the Passenger configuration
Create passenger_wsgi.py like this:
projectname = 'myproject'
virtualenv_root = '/home/jack/virtualenv/' + projectname
import sys
import os
INTERP = os.path.join(virtualenv_root, 'bin', 'python')
if sys.executable != INTERP:
os.execl(INTERP, INTERP, *sys.argv)
sys.path.append(os.path.join(os.getcwd(), projectname))
os.environ['DJANGO_SETTINGS_MODULE'] = projectname + '.prod_settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
Create prod_settings.py like this:
from myproject.settings import *
DEBUG = False
TEMPLATE_DEBUG = DEBUG
ADMINS = (('My Project', 'info#myproject.com'), )
MANAGERS = ADMINS
DATABASES = {} # Appropriately for your production environment
SECRET_KEY = "..." # Your secret key
ALLOWED_HOSTS = ["myproject.com", "www.myproject.com"]
For Django 1.4 or earlier, you need to make some minor modifications, but the same idea works. I've been using variations of this setup since Django 1.2.
I setup virtualenv like this:
# install pip and virtualenv in my home directory
easy_install --user pip
pip install --user virtualenv
# create a virtualenv dedicated to my django project
mkdir ~/virtualenv
virtualenv --distribute ~/virtualenv/myproject
# activate the virtualenv, install django and all project dependencies
. ~/virtualenv/myproject/bin/activate
cd ~/projects/myproject
pip install -r requirements.txt
Notice that after activating the virtualenv, you don't need the --user flag anymore when you install packages with pip. When a virtualenv is active, all packages are installed in that virtualenv.
About requirements.txt:
Create it in your development like this: pip freeze > requirements.txt
Edit it, leave only the packages that your project really really needs. It's better to remove too much and add back later as needed.
Note that virtualenv is not necessary, but recommended. You can do without by setting INTERP in your passenger_wsgi.py to /usr/bin/python. virtualenv is useful to have multiple Django sites with different dependencies on the same account. It is also useful when you want to upgrade Django for your site, so that you can test the upgrade on beta.myproject.com without disrupting traffic on your main site.
Finally, if you are using shared hosting, DreamHost support encourages using different user accounts for each website, but I don't know what difference that makes. Be careful with heavy operations, for example large data imports, because if the process uses much memory, it can get killed by DreamHost. The memory ceiling is unspecified, but it's quite low. So if your site needs to do some heavy operations, you need to make such operations fault tolerant, in order to resume after killed.
I have a django app that I am successfully deplying to heroku. When I dry-run the collectstatic command locally everything works fine.
python manage.py collectstatic --dry-run --noinput
....
Pretending to copy '/Users/hari/.virtualenvs/bsc2/lib/python2.7/site-packages/django/contrib/admin/static/admin/js/admin/ordering.js'
Pretending to copy '/Users/hari/.virtualenvs/bsc2/lib/python2.7/site-packages/django/contrib/admin/static/admin/js/admin/RelatedObjectLookups.js'
71 static files copied.
Despite this ..my django admin staticfiles do not get used and I get a bare-bones django admin site on heroku with Debug set to False.
If I set Debug to True I get a "rich" admin site on heroku. With Debug set to True or False "git push heroku master " command terminal output does not have anything about collecting staticfiles.
I tried the example "helloworld" application that uses gunicorn from Heroku and that did display the "collecting static" messages.I also tried inserting this code snippet into my urls.py. But that too does not help.
from django.conf import settings
if not settings.DEBUG:
urlpatterns += patterns('',
(r'^static/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.STATIC_ROOT}),
Next, I tried adding the following to my heroku config
heroku config:add DISABLE_COLLECTSTATIC=0
But that too did not show my django admin site with all the styles.
Finally I tried switching to gunicorn with my Procfile and that also did not show the admin styles. Only setting Debug=True works to show my admin styles.
I tried this with Django 1.4.2 and 1.5.1 on Heroku and neither is showing me a "normal" admin site. Is there any way out to have my admin files on heroku without going the S3 route.
command terminal output does not have anything about collecting staticfiles.
Looking at heroku-buildpack-python:bin/steps/collectstatic it seems that it tries to do a collectstatic --dry-run --noinput and pipes it's output to /dev/null before displaying the -----> Collecting static files message. This means that if there is an error there that is not present on your local box, you will never see the error on heroku : it will silently fail. (The best kind of failure ;)
have you tried running a one-off worker to test out the collectstatic command and see if it's a problem in their environment?
heroku run python manage.py collectstatic --dry-run --noinput
If this fails, it will give you an error or traceback to look into and further diagnose the issue.
Check this out Django and Static Assets. It seems to be updated recently and you can serve static files nicely using this dj-static package.
Try these three things:
Create this Heroku config variable: DJANGO_SETTINGS_MODULE with a
value of myapp.settings.prod--or as appropriate for your Heroku settings file
Use Whitenoise as described in the Heroku docs:
https://devcenter.heroku.com/articles/django-assets
Check it in and redeploy your dyno: git push heroku master
I found I was missing the first item, the DJANGO_SETTINGS_MODULE" e.g., Command line collectstatic would work but that didn't matter b/c it was an ephemeral dyno
throwing it out there, since dumb mistakes happen:
I spent much time trying to figure out why my module wasn't found on heroku when it was working fine locally, only to realize it was ignored by an entry into .slugignore
I'm trying to get Django's manage.py to run with modified settings files.
I have three settings files
settings.py
preview.py
live.py
settings.py contains my base settings but on live & preview sites I point the ['DJANGO_SETTINGS_MODULE'] to live or preview which in turn load the base file and any settings specific to that environment.
This works fine, until I try to run migrations using manage.py
I updated the manage.py file to import settings.preview but now when I try to run syncdb or migrate I get this error:
django.core.exceptions.ImproperlyConfigured:
You haven't set the DATABASE_ENGINE
setting yet.
My settings file has this in it though:
DATABASE_ENGINE = 'mysql'
How can I get this to work?
Don't modify manage.py if you can help it. Instead pass it the --settings argument to choose an alternate settings module. Setting up a shell script or alias will make it easier to use this.