I am working on follow/unfollow system and I need to add a signals.py file to make the follower count workl, but after I started investigating, I realized that the signals.py file was not being called because it is not on the pycache folder of the app. What can I do to make this file be recognized by django??
apps.py (this is what I tried)
from django.apps import AppConfig
class AccountsConfig(AppConfig):
name = 'accounts'
def ready(self):
import accounts.signals
If you need to see more code or have any questions please let me know in the comments;)
You need to load the module. For example in the AppConfig. In the apps.py you can specify an AppConfig [Django-doc], and load the signals with:
# accounts/apps.py
from django.apps import AppConfig
class AccountsConfig(AppConfig):
# …
def ready(self):
from accounts import signals # noqa
In the __init__.py you also should set this as the default AppConfig:
# accounts/__init__.py
default_app_config = 'accounts.apps.AccountsConfig'
Related
I'm following a tutorial for the Django admin app and I'm trying a step in which the default admin site is replaced with a custom subclass of AdminSite from django.contrib.admin.
My project structure is:
MyAdminTutorial
|- MyAdminTutorial
|- MyActualApp
|- JustAUserApp
MyActualApp.admin.py:
[...other imports]
from django.contrib.auth.admin import UserAdmin, GroupAdmin
class MyAdminSite(admin.AdminSite):
pass
admin.site = MyAdminSite()
admin.site.register(User, UserAdmin)
admin.site.register(Group, GroupAdmin)
MyActualApp.apps.py:
from django.contrib.admin.apps import AdminConfig
class MyAdminConfig(AdminConfig):
default_site = 'MyActualApp.admin.MyAdminSite'
MyAdminTutorial.settings.py
INSTALLED_APPS = [
"MyActualApp.apps.MyAdminConfig",
# 'django.contrib.admin',
....
"JustAUserApp",
]
If I try to run the development server I get this error:
ImportError: Module "MyActualApp.admin" does not define a "MyAdminSite" attribute/class
Messing around in the debugger i found the error stems from a call to getattr() inside import_string() in django.utils.module_loading.py.
For the current call to import_string() the module name and path are set to MyActualApp.admin, getting the current location in the debug console yields the main MyActualApp directory (the project's), but calling getattr(module, "MyAdminSite") triggers the error above.
I expect the MyAdminSite class to be found, but that's not the case, what is going on in this project, what further checks am I not considering?
It turns out that the line which imports UserAdmin and GroupAdmin from django.contrib.auth.admin must be placed after the declaration of whatever classes I want to declare in admin.py. So that the code looks like this:
[...other imports]
class MyAdminSite(admin.AdminSite):
pass
admin.site = MyAdminSite()
from django.contrib.auth.admin import UserAdmin, GroupAdmin
admin.site.register(User, UserAdmin)
admin.site.register(Group, GroupAdmin)
The code works if modified like this, but I'll leave the question unanswered because I have no idea of what is actually going on.
I am trying to test my app but not sure how to configure the django-allauth in the test environment. I am getting:
ImproperlyConfigured: No Facebook app configured: please add a SocialApp using the Django admin
My approach so far is to instantiate app objects inside tests.py with actual Facebook app parameters, an app which functions correctly locally in the browser:
from allauth.socialaccount.models import SocialApp
apper = SocialApp.objects.create(provider=u'facebook',
name=u'fb1', client_id=u'7874132722290502',
secret=u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')
apper.sites.create(domain='localhost:8000', name='creyu.org')
How can I get these tests running? Thanks
Where inside tests.py do you instantiate this app object? If it's inside the setUpModule() method, there shouldn't be a problem.
Personally, I would create a fixture init_facebook_app.json with the relevant information and then inside tests.py (before the test cases) define:
from django.core.management import call_command
def setUpModule():
call_command('loaddata', 'init_facebook_app.json', verbosity=0)
This ensures that the data in the fixture are loaded before the tests are run, and that they are loaded only once, i.e. not before each test. See this for reference regarding call_command.
Lastly, posting your Facebook app secret key anywhere on the internet is not a good idea - I would reset it if I were you.
I would create a migration so all your environments have the data
eg
import os
from django.db import models, migrations
from django.core.management import call_command
from django.conf import settings
class Migration(migrations.Migration):
def add_initial_providers(apps, schema_editor):
import pdb;pdb.set_trace()
call_command(
'loaddata',
os.path.join(settings.BASE_DIR, 'fixtures/social_auth.json'),
verbosity=0)
dependencies = [
('my_app', '001_auto_20160128_1846'),
]
operations = [
migrations.RunPython(add_initial_providers),
]
How can I specify a project level admin.py?
I asked this question some time ago and was just awarded the Tumbleweed award because of the lack of activity on the question! >_<
Project:
settings.py
admin.py (This is what I am trying to get to work)
...
App
admin.py (I know how to do this)
For example, admin.autodiscover() is typically put in the project level urls.py (yes, it will be automatically included in 1.7)
I would like to move this, and the following, into their own admin.py file:
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.models import User
UserAdmin.list_display = ('email', 'first_name', 'last_name', 'is_active')
admin.site.unregister(User)
admin.site.register(User, UserAdmin)
admin.autodiscover()
I tried doing just that, making an admin.py file and adding the code into it. Didn't work.
I tried adding a project level folder called admin, added an __init__.py and threw admin.py into the admin folder. Didn't work
Further I tried adding this admin folder to INSTALLED_APPS in settings.py. No luck.
From the admin.autodiscover doc string:
Auto-discover INSTALLED_APPS admin.py modules and fail silently when
not present. This forces an import on them to register any admin bits they
may want.
And here is the complete function very well documented:
def autodiscover():
"""
Auto-discover INSTALLED_APPS admin.py modules and fail silently when
not present. This forces an import on them to register any admin bits they
may want.
"""
import copy
from django.conf import settings
from django.utils.importlib import import_module
from django.utils.module_loading import module_has_submodule
for app in settings.INSTALLED_APPS:
mod = import_module(app)
# Attempt to import the app's admin module.
try:
before_import_registry = copy.copy(site._registry)
import_module('%s.admin' % app)
except:
# Reset the model registry to the state before the last import as
# this import will have to reoccur on the next request and this
# could raise NotRegistered and AlreadyRegistered exceptions
# (see #8245).
site._registry = before_import_registry
# Decide whether to bubble up this error. If the app just
# doesn't have an admin module, we can ignore the error
# attempting to import it, otherwise we want it to bubble up.
if module_has_submodule(mod, 'admin'):
raise
So the only thing autodiscover does for you is look for some module called admin.py inside installed app directories, hence you can put your admin.py where you want just make sure you import it, this make the code in it (registration of models ect..) get executed.
IMPORTANT: I'm not sure the correct moment for importing your custom-path admin.py. But it's sure you have to import it after load all the related apps.
All admin.autodiscover() is import all the admin files it finds. There is no point putting the line itself in an admin files.
To understand why it's not working, you need to realise how it works. What it does is import the admin.py files inside registered apps. A registered app is a package included in INSTALLED_APPS that has a models.py. That's worth repeating: an app isn't considered if it doesn't have a models.py - even a blank one will work, but without it the package isn't an app.
So if you create a blank models.py in your directory, ensure that that directory is in INSTALLED_APPS, and move admin.autodisover back to urls.py, everything will work.
Edit
I'm not exactly sure what you do want, and why. As I mentioned, autodiscover depends on apps; but as I also mentioned, all autodiscover does is import all the admin files. If you really don't want to follow best practices, all you need to do is import your admin file manually: you can do that in the same place that you normally call autodiscover from, ie in the main urls.py.
Sooner or later, a heavily customized admin class will most likely need a project wide admin.py, as it is the place to register all per-app admins that are not being auto-discovered anymore. The documentation mentions this, but there is no extensive example to illustrate it:
https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#customizing-the-adminsite-class
Note that you may not want autodiscovery of admin modules when using your own AdminSite instance since you will likely be importing all the per-app admin modules in your myproject.admin module. This means you need to put 'django.contrib.admin.apps.SimpleAdminConfig' instead of 'django.contrib.admin' in your INSTALLED_APPS setting.
There is a bit outdated but more or less valid example in the wiki as well for multiple admin sites:
https://code.djangoproject.com/wiki/NewformsAdminBranch
# project-level admin.py
from django.contrib import admin
from myproject.myapp.models import Book, Author
from myproject.anotherapp.models import Musician, Instrument
site1 = admin.AdminSite()
site1.register(Book)
site1.register(Author)
site2 = admin.AdminSite()
site2.register(Musician)
site2.register(Instrument)
I'm curious to see if this gets downvoted. It seems to work, but it feels wrong. ;-)
The question is how to override the UserAdmin settings.
Put an admin.py in your project folder (alongside settings.py)
from django.contrib.auth import admin
from django.contrib.auth.admin import UserAdmin
UserAdmin.list_display = ('email', 'first_name', 'last_name',
'is_active', 'date_joined', 'last_login',
'is_staff')
UserAdmin.ordering = ['-date_joined']
add your project to installed_apps (this seems wrong, but I don't know why)
And now you should see the new columns and sort order on /admin/auth/user/
This is working for me with Django 1.11. So far no issues that I can find. What say you StackOverflow?
this is somewhat related to this question
Why is django's settings object a LazyObject?
In my django project i have several applications. Each application can have its own non-trivial settings file.
proj/
proj/
settings.py
app/
settings.py
views.py
What is the general best practice here?
should app/settings.py do
from django.conf import settings
APP_SETTING= lambda: settings.getattr('APP_SETTING', 'custom_value')
PROJ_SETTING= lambda: settings.PROJ_SETTING
and then in app/views.py do
import .settings
X = settings.APP_SETTING
Y = settings.PROJ_SETTING
or should I be modifying the django lazy settings object in app/settings.py as per the django coding style?
from django.conf import settings
# not even sure how I would check for a default value that was specified in proj/settings.py
settings.configure(APP_SETTING='custom_value')
and then each app/views.py just consumes proj/settings.py via django.conf settings?
from django.conf import settings
X = settings.APP_SETTING
Y = settings.PROJ_SETTING
There are obviously quite a few other permutations but I think my intent is clear.
Thanks in advance.
The simplest solution is to use the getattr(settings, 'MY_SETTING', 'my_default') trick that you mention youself. It can become a bit tedious to have to do this in multiple places, though.
Extra recommendation: use a per-app prefix like MYAPP_MY_SETTING.
There is a django app, however, that gets rid of the getattr and that handles the prefix for you. See http://django-appconf.readthedocs.org/en/latest/
Normally you create a conf.py per app with contents like this:
from django.conf import settings
from appconf import AppConf
class MyAppConf(AppConf):
SETTING_1 = "one"
SETTING_2 = (
"two",
)
And in your code:
from myapp.conf import settings
def my_view(request):
return settings.MYAPP_SETTINGS_1 # Note the handy prefix
Should you need to customize the setting in your site, a regular entry in your site's settings.py is all you need to do:
MYAPP_SETTINGS_1 = "four, four I say"
Since Django 1.7 there is a django-based structure for app-oriented configurations!
You could find descriptive solution here
In this new structure, conventionally you could have an apps.py file in your applications' folder which are embeded in project, something like this:
proj/
proj/
settings.py
app1/
apps.py
views.py
app2/
apps.py
views.py
app1/apps.py file could include something like this:
from django.apps import AppConfig
class App1Config(AppConfig):
# typical systemic configurations
name = 'app1'
verbose_name = 'First App'
# your desired configurations
OPTION_A = 'default_value'
APP_NAMESPACE = 'APP'
APP_OPTION_B = 4
you could have app2/apps.py something different like this:
from django.apps import AppConfig
class App2Config(AppConfig):
# typical systemic configurations
name = 'app2'
verbose_name = 'Second App'
# your desired configurations
OTHER_CONFIGURATION = 'default_value'
OPTION_C = 5
and so etc for other apps.pys in you Django Application folder.
It's important that you should import applications you included apps.py in, as follows:
# proj/settings.py
INSTALLED_APPS = [
'app1.apps.App1Config',
'app2.apps.App2Config',
# ...
]
Now, You could access desired app-based configuration someway like this:
from django.apps import apps
apps.get_app_config('app1').OPTION_A
Not sure about best practices but I don't have any problems with following style:
proj/settings.py
OPTION_A = 'value'
# or with namespace
APP_NAMESPACE = 'APP'
APP_OPTION_B = 4
app/settings.py
from django.conf import settings
from django.utils.functional import SimpleLazyObject
OPTION_A = getattr(settings, 'OPTION_A', 'default_value')
# or with namespace
NAMESPACE = getattr(settings, APP_NAMESPACE, 'APP')
OPTION_B = getattr(settings, '_'.join([NAMESPACE, 'OPTION_B']), 'default_value')
OPTION_C = getattr(settings, '_'.join([NAMESPACE, 'OPTION_C']), None)
if OPTION_C is None:
raise ImproperlyConfigured('...')
# lazy option with long initialization
OPTION_D = SimpleLazyObject(lambda: open('file.txt').read())
app/views.py
from .settings import OPTION_A, OPTION_B
# or
from . import settings as app_settings
app_settings.OPTION_C
app_settings.OPTION_D # initialized on access
My site is just starting and I want a the simplest but flexible configuration solution. That's what I came across with.
# in the end of the site's settings.py
. . .
# Custom settings
MYAPP_CONFIG_FILE = "/home/user/config/myapp_config.ini"
In my application's models.py:
from django.conf import settings
import configparser
config = configparser.ConfigParser()
config.read(settings.MYAPP_CONFIG_FILE, encoding='utf_8')
This config parser is described here. It's convenient enough but definitely not the only option.
you can use django-zero-settings, it lets you define your defaults and a key for your user settings, then it will handle user overrides too.
it also auto imports your settings, has the ability to handle removed settings, and can pre-check settings too.
as an example, define your settings:
from zero_settings import ZeroSettings
app_settings = ZeroSettings(
key="APP",
defaults={
"TOKEN": "token"
},
)
then you can use it like:
from app.settings import app_settings
print(app_settings.TOKEN)
First django app and am having a bit of trouble my project is laid out like this
MyProject
-dinners (python package, my app)
-views (python package)
__init__.py
dinners.py(conflict was here... why didn't I add this to the q.. sigh)
general.py
__init__.py
admin.py
models.py
tests.py
views.py
-Standard django project boilerplate
In my /views/general.py file it looks like this:
import os
import re
from django.http import HttpResponse
from django.template import Context,loader
from dinners.models import Dinner
def home(request):
first_page_dinners = Dinner.objects.all().order_by('-created_at')[:5]
t = loader.get_template('general/home.html')
c = Context({
'dinners':first_page_dinners,
})
return HttpResponse(t.render(Context()))
And in my urls.py file I have this regular expression to map to this view
url(r'^/*$','dinners.views.general.home', name="home")
However when I try to hit the home page I get this error:
Could not import dinners.views.general. Error was: No module named models
Removing the dinners.models import at the top of general.py (plus all of the model specific code) removes the error. Am I somehow importing incorrectly into the view file? Naturally I need to be able to access my models from within the view...
Thanks
UPDATE: answer I had a file dinners.py within the -views package that was conflicting
You need to put a __init__.py file in "dinners" and "views" folder to make those valid packages.
EDIT:
Also, remove that views.py file, that will create conflict with the package.