I need a profile to extend the Django User object, so I thought to create an app to contain the profile object and related views then proceed as per the Django doc, but I get
./manage.py startapp profile
CommandError: 'profile' conflicts with the name of an existing Python module and cannot be used as an app name. Please try another name.
I don't have an app called profile in INSTALLED_APPS and I don't know what context this message should be interpreted in. Can anybody help?
(Yes, I could call it userprofile or xxx_profile instead, but I'd like to understand why I need to)
It conflicts with std lib module profile:
https://docs.python.org/3/library/profile.html
It conflicts with an already excisting library, not made by you
Any other name that isnt a library should be fine
think with me if you have app called math when python tries to import it what it will import your app or the math module in python the modules must have unique names
You Can name it profile_app
Related
I know this might sound stupid but I was just wondering what's the difference if I just type 'myapp' instead of 'myapp.apps.myappConfig' in my Installed Apps list. Is it something related to models or what?
Regards
If you use myapp.apps.myappConfig, then you are explicitly telling Django to use that app config class.
Changing the app config class lets you change the behaviour of the application, for example, when you use the admin app, you can use django.contrib.admin.apps.AdminConfig which autodiscovers apps, or django.contrib.admin.apps.SimpleAdminConfig, which does not.
If you just use myapp, then Django will try to use default_app_config. If that isn't set, then it will use the default AppConfig.
A lot of the time, there isn't any customisation in myappConfig, or default_app_config is set, so you'll get the same behaviour whichever style you use in INSTALLED_APPS.
Ever since AppConfig was added in Django 1.7, the recommendation has been to use ``myapp.apps.myappConfigbecause it's explicit, and avoid usingdefault_app_config`.
However, in practice, it seems that users have preferred the simplicity of using myapp. Therefore, there's an open pull request which will remove default_app_config, and automatically select the app config class when there is only one.
In the Django documentation, a line reads:
New applications should avoid default_app_config. Instead they should require the dotted path to the appropriate AppConfig subclass to be configured explicitly in INSTALLED_APPS.
This suggests I should require users of my app (let's call it sports) to use the following string in their INSTALLED_APPS list:
"sports.apps.SportsConfig"
However, all of the Django apps I use (django-rest-framework, django-cors-headers, django-celery-results) use default_app_config and only require me to specify the first part of the string (in my case "sports").
So how should I write my app? (1) Follow the advice in the docs and force users to write the entire string "sports.apps.SportsConfig" or (2) Follow what all of the other apps in the Django universe are doing and allow users to write only the first part of the string "sports".
I think it completely depends if you want to override custom default values of Class AppConfig for your app.
My Opinion: It's better to create CustomAppConfig (for eg. sports.apps.SportsConfig) by inheriting from Class AppConfig only for apps you create in your Django projects. Because you can tune different parameters like name, label, a verbose_name for admin panel.
Using Django 2.2, how can I run code once after the code has been loaded but before any request is handled? (Similar to code executed in Rails initializers).
The use case is the following:
I'd like to create a pool of connections to a database and assign it to a global variable in a module but preferably not during module import.
(Initially following: https://stackoverflow.com/a/1117692/3837660, I was doing it at module import. But this is not optimal. Partly because I am facing a double import issue which I haven't solved yet and partly because I'd like to avoid creating a pool of connections at module import time.)
It should be done exactly once (no matter if that module happens to be imported twice) but at the application start (not on the first request).
=============================
EDIT:
Apparently running
python manage.py runserver localhost:8000
will call manage.py main twice. As a consequence, everything is imported twice and the ready function is also called twice.
I think you can take advantage of the django AppConfig, docs here -> https://docs.djangoproject.com/en/2.2/ref/applications/#django.apps.AppConfig
from django.apps import AppConfig
from django.utils.translation import ugettext_lazy as _
class YOURAPPNAMEConfig(AppConfig):
name = 'YOURAPPNAME'
verbose_name = _('VERBOSE APP NAME')
def ready(self):
CODE YOU WANT TO RUN ON APP READY
Let us know if this helps you.
I have two apps login and someother
I am trying to import a function like
From login.views import save
In someother.views.py
But getting ImportError: No module named views
I found the answer to my question.
Here it is.
My app name was "login" and have feature.py in the same.
when i tried to import feature using
from login import feature
IDE was not showing any issues. intellisense was working fine.
but when i tried to runserver it thrown ImportError: No module named feature.
and as soon as i changed login to extended_login it worked.
So i think some Keywords are not acceptable as app names or there is already a (system) app named with that keywords which actually do not have a module you trying to import.
I will be brief: to work in the spirit and idea of a Django app, it is ok for an app to import models from inside another app ? Say, a User statistics app will import models from a User app something like: from users.models import users
The answer is yes. It's perfectly okay for one application inside your django project to import models from another application. The power of a django project lies in the apps and their interactions.
Also make sure that you have utility applications importing models from more generic applications and not the other way. So "userstatistics" app should import models from the "users" app but "users" app should not rely on the "userstatistics".
If your app is importing models from a 3rd party application (lets say django-piston), be sure to specify that in a requirements file.
If you're building an internal app that has no chance of ever being released to the public, sure, do whatever you want.
If you're building an internal app that has little chance of ever being released to the public, but will possibly be used by future/current developers, sure, but be sure to document what the app needs to work properly.
If you're building an app for public release, try to keep it self-dependent (and django-internals dependent, ie, use what django provides, when possible). If you really need a third-party app to work, or if a third party app would make your code more manageable, then sure, include dependencies, but be doubly sure to document all requirements and necessary setup.
In most cases, you can do almost whatever you want so long as you have sufficient documentation.
I do, however, have to question the sanity of making your own User model that has the same name as django's builtin auth.User.
You cand try better extending the Django User model with inheritance. You will use the django user with custom field added, so you will have the same user for all the apps.
You can directly import models in app2/models.py. Usually you might need a foreign key, which looks like
models.ForeignKey('app1.ModelClass1', on_delete=models.CASCADE, related_name='modelclass2')
Don't do this. They will have the same app name and the ORM will be confused. Use an abstract model instead, and have both derive from it.