Develop Reference

Django - no migrations folder after refactoring projects and apps names

I have refactored my app and project names, but after that Django doesn't create migrations folder in my app and doesn't actually apply my models migrations.
Even after migrations (with no warning nor error) I have no tables with my objects.
Does anybody know how to force django to do those migrations?

There can multiple reasons behind it. Please check following if you are missing something.
The app must have migrations/__init__.py folder. It automatically creates but if you did code refactoring. You can miss this.
Check INSTALLED_APPS in settings.py it should have the same app name as in admin.py.

Django - How To Make Migrations For Reusable App

I generally use django as a full-blown web app, and am now attempting to make my first pull request on a reusable application. I normally create migrations like this:
python manage.py makemigrations
Of course, since this is a reusable application there is no manage.py file. Even if I add one, there is no settings.py file to point the manage.py to.
What is the accepted way to create migrations for a reusable django application?

The answer is that there IS a settings.py file in each application, I just overlooked it.

What is the purpose of adding to INSTALLED_APPS in Django?

Most documentation simply tells you to add the name of each of your apps to the INSTALLED_APPS array in your Django project's settings. What is the benefit/purpose of this? What different functionality will I get if I create 2 apps, but only include the name of one in my INSTALLED_APPS array?

Django uses INSTALLED_APPS as a list of all of the places to look for models, management commands, tests, and other utilities.
If you made two apps (say myapp and myuninstalledapp), but only one was listed in INSTALLED_APPS, you'd notice the following behavior:
The models contained in myuninstalledapp/models.py would never trigger migration changes (or generate initial migrations). You wouldn't be able to interact with them on the database level either because their tables will have never been created.
Static files listed within myapp/static/ would be discovered as part of collectstatic or the test server's staticfiles serving, but myuninstalledapp/static files wouldn't be.
Tests within myapp/tests.py would run but myuninstalledapp/tests.py wouldn't.
Management commands listed in myuninstalledapp/management/commands/ wouldn't be discovered.
So really, you're welcome to have folders within your Django project that aren't installed apps (you can even create them with python manage.py startapp) but just know that certain auto-discovery Django utilities won't work for that application.

How is a django app different from a python package?

If I create a normal python package (with __init__.py), instead of manage.py startapp won't I still be able to use it like a django app.?

Django app is actually a python package that follows the Django convention. Django-admin startapp is just a helper command to create the files in that convention. If you want to create an app without using startapp, then can create a folder and create __init__.py file and create the necessary files(for views and models). And you should include it in the INSTALLED_APPS. That's all.

Yes, you will be able to use it as a django app. Django is a web framework, hence its main aim is to allow their users to focus on their applications rather than to make them hard-code every single bit of information.

Unable to execute Django runserver and no suggested solution seems to work

I've run Django servers on localhost before and have never run into this problem. I'm desperately trying to figure out what I've done wrong.
I'm using Django 1.4 with Python 2.7 on Ubuntu 12.04.
As far as I can tell I've configured everything correctly - I'm actually using another functional Django project I built as a go-by.
If I run the following command (or any recommended variation thereof) I receive an error.
django-admin.py runserver localhost:8000
Here is the error:
ImportError: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.
Can someone please enlighten me as to why this error is occurring, how to fix it and why it doesn't happen with my other Django project?!?
I've found many posts regarding this problem just by doing some quick Google searches, but none of the suggested solutions have helped - nor do I truly understand them.

I'm pretty sure you're supposed to run
manage.py runserver
from inside your project directory. It automatically loads your settings.py, etc.
From the Django docs:
Generally, when working on a single Django project, it’s easier to use manage.py. Use django-admin.py with DJANGO_SETTINGS_MODULE, or the --settings command line option, if you need to switch between multiple Django settings files

Providing some more code or examples of your directory structure might help.
First, the command is generally manage.py runserver 8000, so try that, and that make might a difference.
Second, in Django 1.4, the location of the settings.py file was moved. In previous versions of Django, the directory structure looked like this:
myproject/
settings.py
views.py
urls.py
myapp/
models.py
...
...
However, in Django 1.4, the main project settings and files were moved to a different directory:
myproject/
myproject/
settings.py
views.py
urls.py
myapp/
models.py
urls.py
...
...
So if you're using Django 1.4 but going off of previous examples, your settings.py might be in the wrong place. Additionally, I've found that when running django-admin.py startproject, it sometimes incorrectly creates two settings.py files, once in the old location and one in the new, which could be additionally confusing you. The only one that manage.py would pay attention to is the one in the project's directory.
If it turns out that your settings.py is in the wrong place but you don't want to move it, as your error suggests, you could set an environmental variable called DJANGO_SETTINGS_MODULE as the path to the Django settings.py you'd like to use for your project. I definitely don't recommend doing this.