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 v2+ how to properly use AppConfig for reusable apps

After Django's 8 part tutorial there is an additional "Advanced Tutorial" which gives a quick-start like approach into python packaging. Namely, moving the Django tutorial app "polls" outside of a Django project and preparing it to be pushed to PyPi.
While this information is useful and covers a bit more ground that Python's own packaging tutorial (e.g. the MANIFEST file to include static / template resources). It doesn't quite explain how to make an app reusable in the sense of configurable options.
For example, if the app has a runtime dependency variable my_bool, how one would open up setting this option for their reusable app.
My first instinct was AppConfig. However, subclassing AppConfig for this purpose isn't explained in the documentation.
One could assume that all the options / settable variables come from the main settings.py file and set defaults if not there... but that also isn't explicitly stated or recommended in any of the Django docs that I have read thus far.
For a reusable application I am making, I would like the user to be able to augment the app with their own data files.
Thus they would need to supply these files in a directory somewhere (with a specified, designated structure) and then tell my app where they are e.g. MY_APP_DATA_DIR="os.path.join(BASE_DIR, <location>)".
Where would such variables go in a reusable Django app?
Would one use a dependency like python-decouple to grab these values?

Run some initialization code when Django (1.9) loads

I saw that from 1.7 there is https://docs.djangoproject.com/en/dev/ref/applications/#django.apps.AppConfig.ready, however this is per each app.
What I am looking for is a way to call some initialization code when Django is loaded, regardless of which apps it contains.
Many people suggest adding the code to wsgi.py, urls.py and settings.py, however all these methods are 'dirty'.
My scenario is that I have several apps that could be part of the Django deployment, and I would like any subset to have this init code.
I could write a special common app, but I assume there must be a Django way of providing init code.

In newer versions of Django, you generally have a project directory containing the global, app-independent files like settings.py and wsgi.py. You can add global initialization code to __init__.py in that directory.
Be advised that this code is run very early (even before the settings are loaded), so some parts of the Django API are not available yet.

Adding several apps to INSTALLED_APPS at once

I am working on an app, which requires another app to be installed. I can add it to my setup.py and it will install the other app too.
After installing my application, i need to add it to INSTALLED_APPS, but i need to add the external app too.
Is there a way to pass the other application implicitly?
What's the recommended way to handle that kind of dependency to avoid asking the users to add more than one app when it is required?

Without doing some strange hacking, there's no way to do this, nor should there be. The user should be aware of what they are adding to their project and what dependancies are required. Remember Django's design philosophy:
Explicit is better than implicit
Have a look at some of the following apps. They all require dependancies in the INSTALLED_APPS. They make it clear in the docs that the user has to add them to their project manually:
Django Zinnia
Django Admin2
Django Filer
Django Filebrowser

There is a library called django-autoconfig that lets you do this. You basically include an autoconfig.py in your app, and if your app is include in INSTALLED_APPS, it's autoconfig.py is loaded.
The file should look something like this:
SETTINGS = {
'INSTALLED_APPS': [
'external_app_1',
'external_app_2',
],
}
Read the docs for more information about ordering and more advanced stuff like that.

Why django has collectstatic?

Thinking about a project that has an app called 'website', and has a 'static' folder inside, that contains all the project's static files, why do I have to collect all static files and put at another folder, instead of just map the static folder (website/static) on my webserver? What's the real need to Django collect static files? Just because there are a lot of apps, and you could put your static file in different folders? Or, are there more than that involved?

Because of the pluggable app philosophy of django made apparent by their whole encapsulated app structure (urls, views, models, templates, etc., are app specific).
You can see this philosophy pressed further in the latest django project structure where project names are not to be included in the imports / apps are imported globally: from myapp import models and not from project.myapp import models
If you install an app from a third party, you don't need to painstakingly figure out where the application lives, django can simply move it to your environment specific static file serving location.
Simply add to INSTALLED_APPS and you can gain almost all of the functionality of a third party app whose files live who knows where, from templates to models to static files.
PS: I personally don't use the app-directory static file system unless I am making an app pluggable. It's harder to find and maintain IMO when files live absolutely everywhere.