Why django has collectstatic? - python

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.

Related

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?

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.

Should templates, views, and models go in the Django config app?

Is it considered against Django "best practices" to place templates, views, or models inside the Django config app? (The same app with settings.py)
Templates are probably a "no" because template files in a templates directory under the config app will not be found by default, I had to add a django.template.loaders.filesystem.Loader to load them.
Thank you for any advice.
There’s no restriction that a project package can’t also be considered
an application and have models, etc. (which would require adding it to
INSTALLED_APPS).
https://docs.djangoproject.com/en/1.11/ref/applications/
Its normally a good practice to leave your project directory as such and keep the apps in their own separate directory and have them defined in the settings.py. This will make your project much more organised and easy to maintain.

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.

Can I put my views.py file in the project folder of django?

I am developing a project using django python server. I have created my project on django and put all my files including views.py in the project folder and I am using it without creating any app and its working fine.
Is this the right way of doing it (or) I need to create an app instead and put all my files in the project ?
This will work fine. Views can be wherever you want.
You can add the package that is your site (the one that has settings.py in it) to INSTALLED_APPS, and then a models.py in it, management commands, et cetera will also work fine.
Apps are handy when things become big and you want to split them into smaller parts.

Categories

Resources