I've problems running the simplest django project within GAE.
After running django-admin startproject myproj (Using django 1.4 from Google SDK), the folder hierarchy look as:
+ myproj (root folder of project)
- manage.py
+ myproj (a sub folder for the project files)
- __init__.py
- settings.py
- urls.py
- wsgi.py
I then add the usual app.yaml to the root folder - that is to the same folder where manage.py is.
application: u-pavarotti
version: 1
runtime: python27
api_version: 1
threadsafe: true
libraries:
- name: django
version: "1.4"
builtins:
- django_wsgi: on
syncdb, dbshell, shell ... works great. Even manage.py runserver works file. However, trying to run dev_appserver fails. The exception I get is:
ImportError: Could not import settings 'settings'.
Well, taking a look at google/appengine/ext/django/main (which django_wsgi is basically setting a URL handler for .* to the google.appengine.ext.django.main.app) is appears that it expect to find settings in the python path. But without doing anything, the module to import is myproj.settings (as myproj isn't in the path).
Now, adding .../myproj/myproj (the lower folder) to the PYTHONPATH solve everything on my dev machine, but as I have no control on the search path on the GAE deployment - this solution won't work.
I can move all files, or just settings.py up to the upper myproj, or move app.yaml down (kinda same thing), but it requires various changes form the default genereated settings.py - and I don't this is the way to go. Alternatively, I can write my own handler, which will instantiate django.core.handlers.wsge.WSGIHandler (old tutorials used to do that) - again, seems against the intention of at least the creators of the 'builtin' attribute of app.yaml.
I wonder how everyone else is solving this issue, and what is the right thing to do.
You can declare the environment variable DJANGO_SETTINGS_MODULE in your app.yaml:
env_variables:
DJANGO_SETTINGS_MODULE: 'myproj.settings'
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 keep getting an error that says no module named backend, this is the directory where my webapp2 application is.
My folder structure:
/project
/backend
/env #python virtual env libraries
main.py #my main entry point where webapp2 app instance is
requirements.txt
app.yaml
My app.yaml:
service: default
handlers:
- url: /dist
static_dir: dist
- url: /.*
script: backend.main.app
libraries:
- name: webapp2
version: latest
- name: jinja2
version: latest
Before my app.yaml was in backend, but I decided to move to root. Now when I run dev_appserver.py in root, I keep getting ImportError: No module named backend
I created the virualenv and installed the requirements.txt packages inside the backend directory.
EDIT: I am unsure if this makes a difference, but I have already deployed my application when the app.yaml was inside the backend folder. I am guessing this should not matter since I am trying to test locally by moving the app.yaml in my project root and running dev_appserver.py app.yaml, but it seems to not work when I do this.
The directory containing the app.yaml file for a GAE service is the service's top-level directory. The content of this directory is what will be uploaded to GAE when you deploy the service. All paths referenced in the service's code or configurations are relative to this top level dir. So moving the app.yaml file around without updating the related code and configurations accordingly will break the app's functionality.
You don't seem to grasp the meaning of the script: statement very well. From Handlers element:
A script: directive must be a python import path, for example,
package.module.app that points to a WSGI application. The last
component of a script: directive using a Python module path is the
name of a global variable in the module: that variable must be a WSGI
app, and is usually called app by convention.
Note: just like for a Python import statement, each subdirectory that
is a package must contain a file named __init__.py
So, assuming your app.yaml file is located in your project dir, the
script: backend.pythonAttack.app
would mean:
having an __init__.py file inside the backend dir, to make backend a package
having a pythonAttack.py file in the backend dir, with an app variable pointing to your webapp2 application
According to your description you don't meet any of these conditions.
My recommendation:
keep the app.yaml inside the backend dir (which doesn't need to be a python package dir)
update its script line to match your code. Assuming the app variable for your webapp2 app is actually in the main.py file the line would be:
script: main.app
run the app locally by explicitly passing the app.yaml file as argument (in general a good habit and also the only way to run apps with multiple services and/or a dispatch.yaml file):
dev_appserver.py backend/app.yaml
store your service python dependencies inside a backend/lib directory (to follow the naming convention), separated from your virtualenv packages
store the env virtualenv package dir outside the backend directory to prevent unnecessarily uploading them to GAE when deploying the service (and potential interference with the app's operation). The goal of the virtualenv is to properly emulate the GAE sandbox locally so that you can run the development server correctly.
Potentially of interest for structuring a multi-service app: Can a default service/module in a Google App Engine app be a sibling of a non-default one in terms of folder structure?
The problem is django server is restarting when I change the settings.py, that does not belong to my django project.
Here is the folder structure.
- project
- django-conf
- settings.py
- urls.py
- ...
- apps
- apps1
- ...
- scrapy-setting
- settings.py <------- file to be updated
When I update the scrapy-setting/settings.py django server will reload.
I don't know why.
In my django config, there is no relation to that folder.
You have three options:
Use noreload flag. BUT this will prevent reload for the whole app.
A monkey patch over the autoreload module, obviously not recommended.
Move the external code out of the Django project
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'm a Django newbie, but fairly experienced at programming. I have a set of related applications that I'd like to group into a sub-application but can not figure out how to get manage.py to do this for me.
Ideally I'll end up with a structure like:
project/
app/
subapp1/
subapp2/
I've tried manage.py startapp app.subapp1 and manage.py startapp app/subapp1
but this tells me that / and . are invalid characters for app names.
I've tried changing into the app directory and running ../manage.py subapp1 but that makes supapp1 at the top level. NOTE, I'm not trying to directly make a stand-alone application. I'm trying to do all this from within a project.
You can still do this :
cd app
django-admin startapp subapp1
This will work (create the application basic structure), however app and subapp1 will still be considered as two unrelated applications in the sense that you have to add both of them to INSTALLED_APPS in your settings.
Does this answer your question ? Otherwise you should tell more about what you are trying to do.
According to Django documentation,
If the optional destination is provided, Django will use that existing directory rather than creating a new one. You can use ‘.’ to denote the current working directory.
For example:
django-admin startapp myapp /Users/jezdez/Code/myapp
So, you can do it by this method:
Create sub_app1 directory in app directory
python manage.py startapp sub_app1 app/sub_app1
Django doesn't support "subapplications" per se. If you want code to be collected in packages within an app then just create them yourself. Otherwise you're just asking for pain.
Its Simple
Step 1 - Create Project
django-admin startproject app
cd app
Step 2 - Create api folder
mkdir api
cd api
touch __init__.py
cd ..
Step 3 - Create nested apps
python manage.py startapp user ./api/user
python manage.py startapp post ./api/post
python manage.py startapp comment ./api/comment
Step 4 - Register nested apps
INSTALLED_APPS = [
...
'api.user',
'api.post',
'api.comment',
]
Step 5 - Change name of Apps
Update the name in apps.py files in all three apps
class UserConfig(AppConfig):
default_auto_field = 'django.db.models.BigAutoField'
name = 'api.user'
class PostConfig(AppConfig):
default_auto_field = 'django.db.models.BigAutoField'
name = 'api.post'
class CommentConfig(AppConfig):
default_auto_field = 'django.db.models.BigAutoField'
name = 'api.comment'
and We are done!
Note : Step 2 is important
Go to your apps folder. Try:
python ../manage.py startapp app_name
django-admin.py startapp myapp /Users/jezdez/Code/myapp
Reference: Django Admin documentation
In order to create a nested app in the Django project, you have to follow the following steps:
Create a subdirectory in the parent directory where you want to add a sub-app.
mkdir finances/expences
N.B: Here finances is the existing parent app and expenses will be the next nested sub-app.
If the subdirectory is created successfully then run the following command in the terminal.
python manage.py startapp expenses finances/expenses
Please check the expenses subdirectory is now looks like a Django app and will behave like that.
Don't forget to register this app in the settings file and change the name from the config file of the app expenses, like -
class ExpensesConfig(AppConfig):
default_auto_field = 'django.db.models.BigAutoField'
name = 'finances.expenses'
Here, the name was only 'expenses' but it has been changed to 'finances.expenses' otherwise no migrations will be applied.
Use this command in the terminal:
python manage.py startapp application_name
there is really no any differ if you use django-admin or manage.py in this case - both will create
https://docs.djangoproject.com/en/4.0/ref/django-admin/#django-admin-and-manage-py
In addition, manage.py is automatically created in each Django project. It does the same thing as django-admin but also sets the DJANGO_SETTINGS_MODULE environment variable so that it points to your project’s settings.py file.