remove default apps in INSTALLED_APPS - python

I'm new to Django and python in general and i'm trying to set up a RESTful api using Django and Django Rest Framework, so my problem is that i want to get rid of the default installed apps, something like this:
INSTALLED_APPS = [
#'django.contrib.admin',
#'django.contrib.auth',
#'django.contrib.contenttypes',
#'django.contrib.sessions',
#'django.contrib.messages',
#'django.contrib.staticfiles',
'rest_framework',
'myapp',
]
since i want a simple api (with no UI) that provides me with some data. But when i run python manage.py makemigrations i get the following error:
LookupError: No installed app with label 'admin'
does this mean these apps are essential?
Thanks in advance.

Keep in mind that Django Rest Framework inherit a lot from Django, and if you are using other packages they likely do the same too; you are free to remove some apps (e.g. django.contrib.sessions if you your are not going to use them) but it depends on what you are going to do in your project.
In particular the error you are referring to is caused by the removal of django.contrib.admin which provides the admin interface for your project, very useful in the development phase. You can read more about it here.
If you have created your app with the standard django-admin startproject and django-admin startapp by default you are importing the admin app form urls.py and admin.py files with this line of code:
from django.contrib import admin
Just get rid of it (and the consequent code in admin.py and urls.py which is referring to the admin app) and the error should go away.
Each application has its own purpose. You can learn more about that here:
django.contrib.admin: documentation;
django.contrib.auth: documentation;
django.contrib.contenttypes: documentation;
django.contrib.sessions: documentation;
django.contrib.messages: documentation;
django.contrib.staticfiles: documentation.
Once you understood the purpose of each app and having clear the features of your project and the packages you'll be using you can choose which applications are to be removed; although at least for the beginning, while you are learning, i personally suggest you to simply keep all of them just to be safe, considering that they are providing very basic functionalities.

Related

Install Django apps through the Django admin-site like plugins in Wordpress

I want to implement a module-manager in Django where third-party modules can be installed through the django admin interface (without changing the code-base of the main project). Or it could also be a service that runs on top of django.
These modules should have the same capabilities as a django app. For example, defining models and views, making migrations, and interacting with other apps. Similar to how it works with the plugin-manager of Wordpress.
Is there a good way to do this? (and are there reasons why I should not?)
What is a Django app? According to Django Packages
Small components used to build projects. An app is anything that is installed by placing in settings.INSTALLED_APPS.
Generally speaking, here are the steps to have an app working in Django
Install the app
pip install app
Register the app in one's settings.py
INSTALLED_APPS = [
...
'app',
...
]
In some cases they'll require to sync the database. Such is the case with social-auth-app-django. Here you'd have to do as well
python manage.py migrate
In some other cases they require specific versions of Python, Django, ect, so that'd have to be taken in consideration too. Such is the case with Django REST framework which requires
Python 3.6+
Django 4.1, 4.0, 3.2, 3.1, 3.0
It's possible as well that apps are dependent on certain Python libraries. Then, one would have to install them too.
For a basic version of that, one wants to create a place to have a button to install an app as well as a model to store the app. The model will keeps track of specific variations with BooleanField.
More precisely, since we now know some apps require database sync, the app model will have requires_db_sync = BooleanField(default=False). Then, if that's true, when installing that app one will want to run at least steps 1, 2 and 3.
One will eventually want to do a thorough analysis of the existing apps and understand the different possible variations (dependencies, requiring DB sync, etc).
I work with WordPress too and this was a thought that came to my mind a few years ago. I didn't pursue it because for most apps I still had to go to the code and do various configurations.
To deal with that, WordPress plugins, like WPForms, come with pages where one does that configuration.
Since such Django app configuration pages for configuration don't yet exist, they'd have to be created as well.
Also, would be great to have a trusted agency with standards to validate an app as good to be in that system.

When creating a package, how do I manage migrations of a weak dependency?

I have a Django app that I would like to package and offer the community through PyPI repository. Its only strong dependance is Django. It also integrates nicely with Django CMS and offers additional integration for Django CMS. I plan to offer this additional functionality only to projects with Django CMS installed. (This is what I call a weak dependency - will install and work without it, but work even bitter with it.) Specifically, some models are only defined if the base model CMSPlugin from Django CMS is installed.
Is there a good/right way to manage migrations, though?
I cannot include migrations of models depending on CMSPlugin in the package since users w/o a Django CMS installations will not be able to run it.
If I omit the migrations depending on CMSPlugin users with Django CMS will create them on first installation. I fear, however, that on every update of the package those migrations will be lost on pip install upgrade when the package is overwritten.
Since these models are not necessarily used in your package it is best to have them in another Django app, which can be a sub-app of your app or perhaps just one of the apps present in your package. If a user has installed CMSPlugin then they can now simply add this extra app of yours to the INSTALLED_APPS list to use it, this also comes with the benefit that your users now have the choice to use it or not.
This way you can also easily adapt your views if this app is installed or not by using the app registries is_installed method [Django docs]:
from django.apps import apps
def some_view(request):
if apps.is_installed('yourpackage.path.to.weak_dependency_subapp'):
# Weak dependency is present
else:
# Weak dependency is absent
Note: You would have to be careful though that you don't import this apps models if it is not installed, otherwise it may give you some error since it would not be loaded.
Edit: To make the sub-app you can either do as you did by cd'ing to the apps directory and python ../manage.py startapp subappname or directly python manage.py startapp subappname <your_app>/subappname (The directory subappname needs to be made first) and then setting it's app config's name attribute to <your_app>.subappname.

Two ways of including an app in INSTALLED_APPS

Say I have an app called polls.
What is the difference between including an app in INSTALLED_APPS like this 'polls.apps.PollsConfig' and just specifying the app's name ( 'polls')?
The official Django tutorial recommends the former.
The latter is the old way and it has got problems in some cases with the position in INSTALLED_APPS as the preferred way has been to put your apps the last, so all your dependencies are already available when your app is loaded.
The former is the new improved way when you load your app configuration instance first and so all the dependencies are aware of your app and also your app prior to loading has got all the dependencies available.
You should use AppConfig and put it at the top of the list, plain app positioned last is relict of the past.

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.

If I install Django CMS will it still show my current work in Django admin

I'm totally new to Python and I've been learning how to use Django and it's admin functionality to work with my models. My question really is how, if I were to install Django CMS, would work with the admin?
My understanding it limited so I wanted to check as I'm struggling to know if it will still show the model's that I've been making in the same /admin/ url (as i read you login to the cms part via the /admin/ url).
Would installing the CMS overwrite anything current in my /admin/ view, or would the data management merely appear within the CMS control panel?
The Django CMS is a totally different environment. You can't install it on top of your current project. So if you want your models inside django cms you have to migrate them manually to the new enviroment. Maybe their are solutions for it but I'm not aware of them.

Categories

Resources