Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

I just pushed a patch based on this discussion: https://github.com/django/django/commit/2ff93e027c7b35378cc450a926bc2e4a446cacf0 On 22 janv. 2014, at 00:08, Russell Keith-Magee wrote: > For my part, it's a light smell, in that it's a configuration variable that's > in a

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Wed, Jan 22, 2014 at 2:03 AM, Carl Meyer wrote: > On 01/21/2014 06:48 AM, Russell Keith-Magee wrote: > > As Marc indicated in his post, I don't think we should be treating this > > as a permanent feature of the API, but as but as a migration aid. Yes, > > default_app_config

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Tuesday 21 January 2014 20:03:25 Carl Meyer wrote: > On 01/21/2014 06:48 AM, Russell Keith-Magee wrote: > > As Marc indicated in his post, I don't think we should be treating this > > as a permanent feature of the API, but as but as a migration aid. Yes, > > default_app_config will exist as a

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 01/21/2014 06:48 AM, Russell Keith-Magee wrote: > As Marc indicated in his post, I don't think we should be treating this > as a permanent feature of the API, but as but as a migration aid. Yes, > default_app_config will exist as a bad smell for 2 releases, but come > Django 1.9, we can remove

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Mon, Jan 20, 2014 at 11:09 PM, Jannis Leidel wrote: > On 19.01.2014, at 08:56, Russell Keith-Magee > wrote: > > > Hi all, > > > > First off - this isn't critical for 1.7 alpha - I'm raising it now > because I've been in this space for the last

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

An interesting related problem hasn’t been raised yet. Since Django 1.7 is much more strict about the import sequence, apps that do stuff at import time will most likely break with RuntimeError("App registry isn't ready yet.”). They will have no choice but to run their initialization in

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

Hi Marc, On 01/20/2014 01:23 PM, Marc Tamlyn wrote: > 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

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

n 2014-01-20 20:22, Aymeric Augustin wrote: > The alternative is to modify INSTALLED_APPS to support passing > arguments to the AppConfig class. But I find it rather ugly. [I've only been lurking in this thread, so take with a grain of salt; just throwing it out there to see what sticks] Would

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

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

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

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

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

Hi all, I just filed #21831, which is a release-blocking regression directly related to this. My opinion is that doing check-registration as an import side-effect in `__init__.py` is not viable, as it means that every single check needs to be coded defensively against the possibility that the app

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 01/20/2014 12:22 PM, Aymeric Augustin wrote: > On 20 janv. 2014, at 18:36, Carl Meyer wrote: > >> I very much hope >> that moving the admin autodiscovery to the admin AppConfig still allows >> some reasonable path to opt-out of autodiscover - perhaps by subclassing >> the

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 20 janv. 2014, at 18:36, Carl Meyer wrote: > I very much hope > that moving the admin autodiscovery to the admin AppConfig still allows > some reasonable path to opt-out of autodiscover - perhaps by subclassing > the admin AppConfig? We could provide

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 01/19/2014 07:08 AM, Aymeric Augustin wrote: > On 19 janv. 2014, at 13:46, Russell Keith-Magee > wrote: > >> On Sun, Jan 19, 2014 at 5:48 PM, Aymeric Augustin >> >

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 19.01.2014, at 08:56, Russell Keith-Magee wrote: > Hi all, > > First off - this isn't critical for 1.7 alpha - I'm raising it now because > I've been in this space for the last couple of days as a result of the > working on the check framework. I suspect any

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

For tracking purposes, I've opened a ticket: https://code.djangoproject.com/ticket/21829 Russ %-) On Sun, Jan 19, 2014 at 10:08 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 19 janv. 2014, at 13:46, Russell Keith-Magee > wrote: > > On Sun, Jan

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 19 janv. 2014, at 13:46, Russell Keith-Magee wrote: > On Sun, Jan 19, 2014 at 5:48 PM, Aymeric Augustin > wrote: > > We can certainly use AppConfig.ready() for new features such as the checks > framework. It’s reasonable to ask

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Sun, Jan 19, 2014 at 9:52 PM, Marc Tamlyn wrote: > For what it's worth, if we have some code that: > > a) is a new feature we want to ensure runs > b) has no obvious, explicit place to place it > and > c) is trivially solved by .ready() > > Then I start to think that

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

For what it's worth, if we have some code that: a) is a new feature we want to ensure runs b) has no obvious, explicit place to place it and c) is trivially solved by .ready() Then I start to think that practicality beats purity. Personally, I think we should still encourage the "explicit"

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

HI Marc, On Sun, Jan 19, 2014 at 5:52 PM, Marc Tamlyn wrote: > All of your proposed solutions require trying to import an apps.py module > which may not exist. I know Aymeric was very much against this, especially > as python imports have potential side effects, and we

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On Sun, Jan 19, 2014 at 5:48 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 19 janv. 2014, at 08:56, Russell Keith-Magee > wrote: > > This is fine, but it limits the logic that we (as a project) can put into > AdminConfig.ready(), because existing

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

All of your proposed solutions require trying to import an apps.py module which may not exist. I know Aymeric was very much against this, especially as python imports have potential side effects, and we don't know what people might have in a apps module already. Anyways, configuration over

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 19 janv. 2014, at 08:56, Russell Keith-Magee wrote: > This is fine, but it limits the logic that we (as a project) can put into > AdminConfig.ready(), because existing projects won't reference the new > AdminConfig. So, cleanups like putting admin.autoregister and

App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

Hi all, First off - this isn't critical for 1.7 alpha - I'm raising it now because I've been in this space for the last couple of days as a result of the working on the check framework. I suspect any changes stemming from this discussion can be landed in the beta period without major problems.