We Keep Coding

Reroute import pathes in django

I want to use a django app (newapp) in my django project. To keep it simply updated, I would like to include it as git submodule, but this will lead to a folder structure like:
myproject
|-app
|-newapp-git
|-newapp
|-settings.py
|-urls.py
|-...
|-README.md
That is because, newapp is unfortuntely not only the appfolder but also some files (like readme) and the subfolder newapp. I can add this in INSTALLED_APPS with newapp-git.newapp, but the app itself imports models etc. with import newapp which does not work, and I cannot change it because I dont want to modify the content in newapp to keep it updated simply.
So, is there a chance to tell django, that imports from newapp should be rerouted to newapp-git.newapp?

django deploying separate web & api endpoints on heroku

I have a web application with an associated API and database.
I'd like to use the same Django models in the API, but have it served separately by different processes so I can scale it independently.
I also don't need the API to serve static assets, or any of the other views.
The complication is that the routes I have defined have the API and the webapp sharing the root domain:
http://domain.com/normal/application/stuff
http://domain.com/api/different/stuff
and additionally my Django apps depend on each other's models and constants (so two different settings.py files with different INSTALLED_APPS doesn't quite solve it).
I guess one way is I could define different processes in my Procfile which just start the Django app, but that in one of the processes it might have different environment variables? I don't think I can change the environment per Proc with heroku:config, I think it would actually have to be a directive in the Procfile.
Anyone have any experience or insight with this? Thanks!

As Daniel said you could just use two settings files, with a shared base. If you want to serve a subset of the urls you should just also create separate url definitions in the ROOT_URLCONF setting.
So your project structure would be something like this:
project/
project/
settings/
__init__.py
base.py
normal.py
api.py
urls/
__init__.py
base.py
normal.py
api.py
wsgi/
__init__.py
normal.py
api.py
settings/normal.py (analog for api) would be somthing like this:
from .base import *
ROOT_URLCONF = 'project.urls.normal

I don't think you need different environment variables, just a separate WSGI file pointing to a different settings.py. Those settings file can import shared settings from a common file, then set their particular values for INSTALLED_APPS. Then the Procfile can refer to those wsgi files in separate processes.

syncdb doesn't create table models

I'm working on a web application with Django framework. I have this structure :
project
web_app
models
models.py
rwtool
settings.py
urls.py
views.py
I defined my models in models.py file. In my settings file I added this line project.web_app in INSTALLED_APPS. When I did
python mange.py syncdb
the models are not created. To create them I must add the project.web_app.models to my settings file. I have looked to others project and they don't do like this and it works. Is it correct what I'm doing?

models.py should be under your app folder (in your case "web_app").
If you want to separate your models then you have to turn models folder into a python package, in this case add an __init__.py in that folder and make sure that in the init file your models are accessible to the outside world at the path "web_app.models.ModelName".
So, solution 1 (standard Django approach):
project
web_app
models.py
Solution 2:
project
web_app
models
__init__.py
ModelOne.py
ModelTwo.py...
the __init__.py will contains something like:
from .ModelOne import ModelOne
from .ModelTwo import ModelTwo
The approach N2 can be also used for views and other stuff too ;)

First add your app to INSTALLED_APPS , and then run
python manage.py inspectdb > somefile.txt
You can get quickly check out if your database structure is matching your django models.
If python manage.py inspectdb > somefile.txt not created any structure, then make sure that your app is added to to INSTALLED_APPS.

Django application override & import path?

Let's have a django project using a 3rd party application.
I'd like to override some of its modules without touching original files.
Simple subclassing is not possible here, need to override code transparently as many other apps rely on original class names and functions.
Project's structure looks like:
django_project/
__init__.py
settings.py
overrides/ <-- here is a subdir with apps overrides
__init__.py
payment/ <-- here is an example of app to override
__init__.py
admin.py
forms.py <-- this file is ignored, original is imported
models.py
tests.py
views.py
settings.py was modified with
INSTALLED_APPS=(
'satchmo_store.shop'
#'payment' # original values
'overrides.payment' # modified app
...
)
The above solution however does not work, because Django does not insert path of added app into modules search path (sys.path).
Django just loads admin.py, models.py, tests.py and views.py, other files like forms.py are ignored.
Is this behaviour documented somewhere ? What exactly placing a module name in INSTALLED_APPS does behind scenes ?
I hacked the situation with hardcoding new modules search path in manage.py and Apache's setting of WSGIPythonPath.
import os.path
import sys
DIRNAME = os.path.dirname(__file__)
APPS_OVERRIDE = os.path.join(DIRNAME, 'overrides')
if not APPS_OVERRIDE in sys.path:
sys.path.insert(1, APPS_OVERRIDE)
I doubt this is the right way. Cann't find a guide describing apps overriding.
So, how can I properly override external Django application in my project ?
The bonus question: Do I need to copy whole application directory tree, not just particular files which are really modified ? As far as I know, Python stops at first matching module path, so it won't import other modules available in following parts of the search path.

Example of how to override your form:
overrides/payment/forms.py
from django import forms
class YourNewFormThingy(forms.Form): pass
overrides/payment/models.py
from satchmo.payment import forms as satchmo_payment_forms
from . import forms
satchmo_payment_forms.SomeForm = forms.YourNewFormThingy

Try including payment as well along with override.payment as satchmo uses payment module to process payments and payment code is flexible enough to include your code as well.

Python and App Engine project structure

I am relatively new to python and app engine, and I just finished my first project.
It consists of several *.py files (usually py file for every page on the site) and respectively temple files for each py file.
In addition, I have one big PY file that has many functions that are common to a lot of pages, in I also declared the classes of db.Model (that is the datastore kinds).
My question is what is the convention (if there is one) of arranging these files.
If I create a model.py with the datastore classes, should it be in different package?
Where should I put my template files and all of the py files that handle every page (should they be in the same directory as the one big common PY file)?
I have tried to look for MVC and such implementations online but there are very few.
Thanks,
Joel

I usually organize my projects in this way:
project
main.py
README
models
bar.py
foo.py
views
foolist.hml
barlist.hml
controllers
controller1.py
controller2.py
api
controllerapi.py
helpers
utilities.py
lib
extfoo.py
db
foo.db
test
test.py
Look at this post; it's a really great article on how to structure a project (not in python but it does not matter).

Typically I organize like so:
project/
main.py
models.py
app.yaml
index.yaml
templates/
main.html
foo.html
...
styles/
project.css
js/
jquery.js
project.js
images/
icon.png
something.jpg
And I have all of my handlers in main.py, all of my models in models.py, etc.
If I have a lot of handlers, and I can easily split the functionality of some handlers from the others (like taskqueue handlers vs. request handlers vs. xmpp/email handlers) I'll add another foo_handlers.py to the mix, but usually I just cram them all in main.py
But then again, I tend not to write hugely complex Python App Engine apps...