Now I have a moment to mention this, there is a very important issue I currently don't see a way around, contrib highlights it well but in reality it's more a third party app issue.
Suppose my third part app has a (normal) Django two-release support principle. Django 1.8 is coming out and although I backed out of using AppConfigs with 1.7 because things were awkward and I preferred to leave the hacks, I'm not going to "do it right" and use AppConfigs. My app has required things which must run in ready() or there will be strange and cryptic errors. There's no obvious way to detect that they haven't been run at the point of use, or this may be too late (for example modifying a model). I update all my documentation to say "you must use the AppConfig now", but I still get 50 users email me complaining that they have cryptic error messages and the whole thing is broken. I personally think that we need some way of telling Django that it *must* use a given AppConfig (unless told otherwise) for an application. I'm quite happy for that method to always throw warnings, perhaps after deprecation throw errors, but I must be able to specify that it needs an AppConfig to work correctly, ideally in such a way that it will tell you what you need to do. Now, personally I don't *like* default_app_config. It smells ugly, and I don't want people to view it as a long term solution. So how about this twist on the suggestion: - Some applications do not require a customised AppConfig, they do not need to do anything. They may have one (e.g. contrib.sites?) but it doesn't provide anything other than customisation hooks. - Some applications require an AppConfig. They can set required_app_config = 'myapp.apps.MyAppConfig' in myapp.__init__. This will be picked up if the user has put 'myapp' in INSTALLED_APPS, and will be used. In Django 1.7, this will throw a DeprecationWarning, and say which app is affected and what the default path should be. In Django 1.8 it will error during django.startup(). The ability to specify required_app_config in this way stays in Django until at least 1.9 if not forever, but which point hopefully we will be near to 100% adoption of AppConfigs in the wild. - We update the docs, tutorial and project template to use AppConfigs all the time, and we advertise them as much as possible. We can now move all the new check code into AppConfig.ready(), and anything else we want. We now have a way of ensuring that they *will* get run without users updating their code, and we're shouting as loudly as we dare to the users to tell them what's going on. Thoughts? Marc [PS, I've opted for accelerated timings on this update path, which I justify on the basis that by using required_app_config we are in a sense changing the configuration of an app that the user has in their settings, therefore a visible warning is justified. However, I'm +0 on doing this over an extra release cycle] On 20 January 2014 20:09, Carl Meyer <c...@oddbird.net> wrote: > On 01/20/2014 01:01 PM, Carl Meyer wrote: > >>> 3a) As for 3, but use a flag on the AppConfig subclass that marks > >>> it as "use me as the default". If there are more than one AppConfig > >>> objects in an apps module that has the 'use as default" flag, raise > >>> an error. > >> > >> This smells like dependency tracking and hard to explain errors. I > >> also don’t see how a user could prevent 3rd party apps to not mark > >> itself as default. -1 > > > > I don't see what advantage this has over (3) - it just allows another > > failure mode. -0. > > I just realized that this option also requires adding an automatic > attempt to import the "apps" submodule within an app, when the "apps" > submodule was not explicitly referenced in settings (effectively making > the "apps" submodule a magic name, and potentially causing immediate > issues for apps that already have an apps.py for whatever reason.) > > So count me as -1 on this option, not -0. (And I'd be similarly -1 on > the "default_app_config", if it were required to be defined in apps.py > rather than __init__.py, for the same reason. But I'm still +1 on it if > it's defined in __init__.py.) > > Carl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/52DD8289.9010808%40oddbird.net > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1Hy%2BUKSMV2%3DtD9V7%2BKFu0pMBSk78AHCnt9MJdi8nQ%2B8eQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
