Develop Reference

Deleting 'models.py' from Django app

In a project, I'm implementing using Django framework, I have two applications:
Application responsible for REST API, containing production models.py file.
Application responsible for Web client, that uses REST API's models.
Both of them contain vast static files and hierarchy of additional source code, that is why it came to my mind to split this responsibilities into two apps, rather than different views.py and urls.py files inside of one application.
Because application responsible for Web relies entirely on REST API's models is it a good practice to delete models.py file from this application entirely?

The file is only generated for your convenience. If you don't need it, there's no reason to keep it. No part of Django relies on it being present.

Django - What constitutes an app?

I'm build a Django app with a number of models (5-10). There would be an admin side, where an end-user manages the data, and then a user side, where other end-users can only read the data. I understand the point of a Django app is to encourage modularity, but I'm unsure as to "where the line is drawn" so-to-speak.
In "best practices terms": Should each model (or very related groups of models) have their own app? Should there be an 'admin' app and then a 'frontend' app?
In either case, how do the other apps retrieve and use models/data inside other apps?

Apps are logical separators. For example, if your site has blogs, polls and feeds, you might have blog, poll and feed apps. Each app might have multiple models (Blog and Post models for blogs for example), but be separated from each other by function.
You don't strictly have to separate things into separate apps if you don't want to. Splitting things into apps does help a lot with overcrowding. If you think you will grow beyond 10 models you might consider splitting up before it becomes too hard (django really doesn't like you to move stuff between apps).
As for accessing things from other apps, each app is a module, so all you do is
from app1.models import App1Model
and you are all set.

Python\Django is modular.
App should include just those models which usually solve 1 concrete task.
If some of models from p.1 can be usefull in other tasks, then probably would be better to create a new apps for those models. Ie if some models are shared between multiple tasks then there is a logic to make a new apps with those models.
For example you have a forum app. This forum has such features like, polls, registrations, PM, etc. Logically everything seems to be combined together. However, if your site is just a forum - ok, but if there are other content, for example blogs with comments, then "registration model" can be made as a separate app and can be shared between parts of site such as "blogs with comments" and "forum".
Regarding admin\frontend. Ive seen apps\projects with more than 10 models together. Based on the forum example above, if the admin part does not do any task out of scope of your app, then I would make admin and front-end inside of one app. Otherwise, if admin has any relation to another task, which is out of scope of your main app - admin should be as a seperate app.

where do I place simple pages in a django application?

I new in django, but I am really old in web developpement.
My question is about how to properrly organize your project into a django project. I am about to build my first web site in django and i have the following question :
I want a contact page in my website? basically it's a form/view/template, but where do I create that ? should I create a whole new app?

Django projects deliver functionality through apps. A project is the configuration holding your chosen apps together. It's highly likely you'll need to write at least one app yourself. Your app will have models, views and forms.
There are a number of projects that can help bootstrap your project. See the matrix on djangopackages.com related to boostrapping.
Pinax is a good application bootstrapping tool providing a standard project layout, starter projects, reusable apps and default templates.
The authors of Two Scoops of Django have a layout on GitHub which is focused on the environment and file/directory layout.

Newbie Django: Creating a project with several apps or all in one

I am begginer in the Django world, I developed some "information sites" (nothing complicated) but this week my boss order me to make a migration of a big software that has 7 modules.
So I went to read the documentation page and search in google for how I could design this software using Django. I know that the every "module" can named as "app", so I create a new project and one app for every module (I dont know if it was right because the modules will not be public).
The problem is that now I don't know what is the next step.
All my apps can share data (every app has its owns models but sometimes one app has a model that was related to the models in other apps)?
Where do I write the code for the login process (I create a manageUsers app that was thinked to handle the registration, edit, share and validate profile of the current or new user ) and we can be able to share this session data accross the apps?
I need one more app for put the website information (like contact, about, pricing ...)? I use Python 2.7, Django 1.3, Memcached and Mysql 5.
If someone can help me or tell me where it may clarify these questions because most explains how to develop using only one app and in the IRC got no reply or else I must be write all the code in one app?
Best Regards

A good place to start (dated, but worth reading; look at user comment bubbles too): http://www.djangobook.com/en/2.0/ . Chapter 1 - 10 are essential reading. You can pick-and-choose to read the remaining chapters, if desired.
Yes, all Django Apps can share data with one another. You make multiple Django Application's, housed under a single Django Project. The Project sets up a common database to use, and each Application creates Models which use said database. App1 can talk to App2 and vice-versa.
Django Project (one) <----->> (many) Django Application
Typically you separate Apps based on common function. User accounts get their own app (see Auth below). Blog postings get another. A Google Maps interface will get another. User subscriptions, another.
For user accounts and login, Django provides the Auth Module. You can have user accounts stored directly in Django, or configure it to talk to something else, like Active Directory. Auth works "pretty good" out of the box, though I personally customized mine a bit to allow 255-character email addresses as usernames (by default, it limits to 40 characters). Chapter 14 in the Django book might be a little easier to read than the official Auth docs. If you do use Auth, you don't have to make your own Django Application, since Auth already is one! You just install it in settings.py and you're golden.
Your Django structure will likely look something like this:
/Project/
__init__.py
manage.py
settings.py
urls.py
App1/
__init__.py
forms.py
models.py
views.py
templates/App1/
template1.html
template2.html
App2/
...
App2 can access the data-models of App1 by doing: from Project.App1.models import someModel

For me, rules are simple.
If you need to copy-paste some code from one project to another - make an app for it
If one of app's modules code is bigger than 1k lines and/or hard to maintain - look for something to move in separate app
Group functionality into apps to minimize cross-linking between them
For interconnection you can use signals and sessions

What is an "app" in Django?

According to the documentation:
An app is a Web application that does
something -- e.g., a weblog system, a
database of public records or a simple
poll app. A project is a collection of
configuration and apps for a
particular Web site. A project can
contain multiple apps. An app can be
in multiple projects.
However, what are other examples of what makes an "app"?

What makes an app (for us) is one thing:
An App Is The Unit Of Reuse
If we might want to split it off to use somewhere else, it's an app.
If it has a reusable data model, it's an app. User Profiles: App. Customers: App. Customer Statistical History (this is hard to explain without providing too many details): App. Reporting: App. Actuarial Analysis: App. Vendor API's for data gathering: App.
If it is unique and will never be reused (i.e., customer specific) it's an app that depends on other apps. Data Loads are customer specific. Each is an app that builds on an existing pair of apps (Batch Uploads, and Statistical History)

Django apps are bundles of reusable functionality. When starting off it's easy to just use one custom app for your project, but the "Django way" is to break it up into separate apps that each only do one thing. You can take a look at django.contrib for examples of really well made reusable apps.
A recent example of mine: a client needed a way to import CSV data into the Django models. The easiest way would be to just add a model with a FileField and write a quick parser for the specific format of what they are uploading. That would work fine until the format changed and I had to go make the parser match. But this is a commonly repeated task (importing data) and unrelated to the existing app (managing that data) so I broke it out on its own. This pluggable app can import data for any active model. Now the next time a client needs import functionality I just add this code to installed_apps and run syncdb.
It's a judgement call when to break out an app onto its own, but the rule of thumb for me is if I'm likely to do something again I'll take the extra time to make it a generic app. That means I've created some tiny apps (some just contain a template tag), but it's little overhead for the future gains.

User management could very well be an app, if you are not going to use Django's built in user framework.
It has user interfaces and defined models for stored data, and it is really separate from the Blog or the Wiki application (although the information will be shared).
As long as both applications are in the same 'project' they should use the same settings for the DB. You should be able to by just making sure the proper models are imported where you are trying to use them.
See this link for a little more information.