Re: Dynamic app loading

Hello Raphael, Thanks for your very, very helpful explanations. Just another 2 questions: I saw that you did two things: 1.: you created a "class ReportsApp(AppConfig):" in /plugins/reports/__init__.py - according to the Django docs[1] this should go into /plugins/reports/apps.py Why in the root

Re: Dynamic app loading

Hi, Am Tue, 31 Jul 2018 23:18:32 +0200 schrieb Christian González : > Whow, I'm quite impressed. Never stumbled upon that. I'll recommend > that for some collegues (to use it...) Thanks =) > But about the internals: Nice, this was the first way I implemented > that as well, and maybe I will come

Re: Dynamic app loading

Hi Raphael, > we are doing such a thing for quite a while in our open source project > pretix[1]. Whow, I'm quite impressed. Never stumbled upon that. I'll recommend that for some collegues (to use it...) But about the internals: Nice, this was the first way I implemented that as well, and maybe I

Re: Dynamic app loading

I stumbled upon a "missing feature" in Django, which I call "dynamic" > app loading, a while ago, since I try to create a Django based > application which can dynamically add plugins to itself. > > I first tried to google the internet, and found many Stackexchange Q&A

Dynamic app loading

; in Django, which I call "dynamic" app loading, a while ago, since I try to create a Django based application which can dynamically add plugins to itself. I first tried to google the internet, and found many Stackexchange Q&A where this topic is handled, but either in an insufficient way

Re: Improving django.setup() and app loading performance

s when app B is imported before app A. Apps that attempt to perform auto-discovery on other apps (such as the admin, debug-toolbar, haystack, etc.) are especially prone to this. This isn’t a theoretical argument. We’ve had these bugs and I spent hundreds of hours refactoring the app-loading proces

Re: Improving django.setup() and app loading performance

In my opinion, those latencies are still a bit high, how much is really used on python/lambda code? On a project of mine without hitting the database and django-rest-framework my times were around 1-4ms excluding any network latency. Debug and loggers might have high impact on your times if it

Re: Improving django.setup() and app loading performance

Ah, interesting! Thanks for tracking that down. In chat we basically discovered that the intercontinental latency and shoddy wifi connections were responsible for a lot of the confusion. Testing from a US-based fiber connection, we got results of ~40ms in both scenarios. --- https://arb9clq9

Re: Improving django.setup() and app loading performance

I think I have found your issue, if I'm not wrong, django won't initialize twice if you call it twice (which was your previous behaviour) at least not completely, since apps registry has a "ready" flag. Check this line: https://github.com/django/django/blob/master/django/apps/registry.py#L66 So

Re: Improving django.setup() and app loading performance

Hm. This is the downside of cloud services - we cannot look under the hood. Since I think that since this is something we _want_ cached, and because it will make the function being executed shorter in length - it is a good code decision to make. Thank you for the idea! However, it looks like the

Re: Improving django.setup() and app loading performance

Rich, I have just performed a real test, with a simple lambda and a datetime.now() defined at the top of the module as I said, and out of 100 requests, this was the result: {u'2016-03-01T00:37:30.476828': [43], u'2016-03-01T00:36:51.536025': [58]} Where the date is the datetime.now() defined at t

Re: Improving django.setup() and app loading performance

That certainly could have something to do with it - there isn't very much transparency about how API Gateway works. It's super new and pretty janky, TBQH. However, I think that the behavior describing is not what's expected - the caching seems to be for the assets of the whole environment, not o

Re: Improving django.setup() and app loading performance

I have repeated the test this time through API Gateway, and out of many calls I only got two different dates that were instantiated at module level, meaning my module was only imported twice. I fail to see why it doesn't behave the same with your code. El lunes, 29 de febrero de 2016, 21:33:05

Re: Improving django.setup() and app loading performance

That's quite odd, I recall testing this once, where I created a lambda which had a datetime.now() at the top, and just returned that value. Out of a few calls, it returned two different results, meaning the module was re used "most" of the time. This was tested calling the lambda from the AWS T

Re: Improving django.setup() and app loading performance

As I suspected, moving setup() outside of the handler had a negligible effect - in fact the test showed a slight drop in performance. :( Testing from httping. From Berlin to US-East-1: Before: --- https://arb9clq9k9.execute-api.us-east-1.amazonaws.com/unicode/json_example/ ping statistics ---

Re: Improving django.setup() and app loading performance

I'm almost sure that right now you are calling setup() with django already initialized in some cases where the enviorment is reused, I'm amazed django doesn't complain when setup() is called twice. El lunes, 29 de febrero de 2016, 21:07:32 (UTC-3), Rich Jones escribió: > > Haven't tried that! I

Re: Improving django.setup() and app loading performance

Haven't tried that! I don't _think_ that'll work.. but worth a shot (I don't think they only cache the handler.. I think they cache the whole environment). Will report back! And as you're mentioning, we really shouldn't be doing it every request, so if there were even a way to cache that manual

Re: Improving django.setup() and app loading performance

Sorry if this looks like a retarded question, but have you tried the setup calls to the top of the lambda_handler module? I'm not sure why you need the settings data as an argument to the lambda handler, but if you find a way to move those 4 lines near setup(), you will only load the whole djang

Re: Improving django.setup() and app loading performance

For those who are still following along, these are the lines in question: https://github.com/Miserlou/django-zappa/blob/master/django_zappa/handler.py#L31 https://github.com/Miserlou/django-zappa/blob/master/django_zappa/handler.py#L68 It's very possible there are ways of significantly improving

Re: Improving django.setup() and app loading performance

Hey all! Let me clarify a few of the terms here and describe a bit how Django operates in this context. "Serverless" in this contexts means "without any permanent infrastructure". The server is created _after_ the request comes in, and it dies once the response is returned. The means that we n

Re: Improving django.setup() and app loading performance

Hi Collin, On Friday, February 26, 2016 at 10:56:33 PM UTC+1, Collin Green wrote: > > Ugh. As a strong advocate of both django and zappa, I'd love it if we > could keep the conversation on target without degenerating into stack > attacks. If you don't want to weigh in, please feel no obligation

Re: Improving django.setup() and app loading performance

Ugh. As a strong advocate of both django and zappa, I'd love it if we could keep the conversation on target without degenerating into stack attacks. If you don't want to weigh in, please feel no obligation to do so. I do agree that we could pare down the profile into more actionable sections. I

Re: Improving django.setup() and app loading performance

Rich, I believe you know a lot way more than me about AWS Lambda since you have made such a great project, and I'm really interested to know how it really works since theyr documentation is a bit superficial. On their FAQ this is what they state: *Q: Will AWS Lambda reuse function instances?*

Re: Improving django.setup() and app loading performance

On Friday, February 26, 2016 at 9:53:00 PM UTC+1, Rich Jones wrote: > > @Aymeric > > In my opinion, the first concrete step would be to measure how much time > is spent executing Django code rather than importing Python modules. > > Over 70% of the total request time is spent in django.setup() -

Re: Improving django.setup() and app loading performance

@Aymeric > In my opinion, the first concrete step would be to measure how much time is spent executing Django code rather than importing Python modules. You can find a complete profile of a Django request as it goes through the complete request/response loop here: https://github.com/Miserlou/dj

Re: Improving django.setup() and app loading performance

If with "serverless" you are talking deployments such as Amazon Lambda or similar, I don't think setup is called on every request, at least for AWS Lambda, the enviorment is cached so it will only happen once each time it needs to scale up. Are there any other issues? El viernes, 26 de febrero

Re: Improving django.setup() and app loading performance

are always good, I’m against changes that would re-introduce non-determism in the app-loading process. Django 1.7 eliminated a whole class of bugs, included some that randomly occurred with low probability when restarting a production server under load. These bugs aren’t fun to track down. T

Re: Improving django.setup() and app loading performance

That might be true in theory.. but in practice? Do any of the core/contrib/top100 apps actually depend on loading orders? I've never encountered that problem before, but I don't know. It seems like we could easily get a 10x performance improvement by doing this in parallel by default, and have

Re: Improving django.setup() and app loading performance

I'm not sure we can load apps in parallel -- they are loaded in the order in which they appear in INSTALLED_APPS so the process is consistent. Maybe it would work for some setups, but I guess it would introduce subtle bugs in others. https://docs.djangoproject.com/es/stable/ref/applications/#ho

Improving django.setup() and app loading performance

(Originally posted this as a ticket, but we can have discussion here and leave the ticket for just more specific discussion.) I imagine that this is an area that hasn't really been given much consideration with regards to optimization, because it is

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 place you wouldn't histor

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 will exist as a bad

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 ba

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 i

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

ouple 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. > > > > Also - Aymeric - you've done a great job with this app loading work. I > didn't g

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

Given that the end result in Django 1.9 will the same, that app-loading will be quite disruptive in any case — most projets won’t even start after upgrading to 1.7, and that default_app_config is trivial to implement, I think it’s worth smoothing the upgrade path. -- Aymeric. -- You received th

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 two-r

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 i

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 although

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 depend

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 admin AppConfig? > >

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 AdminAutoDiscoveryConfig and AdminConfig.

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 >> > > wrote: >> >> Also there might be good reasons for

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

any changes stemming from this > discussion can be landed in the beta period without major problems. > > Also - Aymeric - you've done a great job with this app loading work. I didn't > get much of a chance to follow along as it was unfolding, but the resultant > work ha

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 19, 2014 at 5:48 PM, Ayme

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 our users to edit their configuration to > take advantage of

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 practicality beats purity.

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" approa

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 don't know what > people m

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 projects won't reference

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

m this > discussion can be landed in the beta period without major problems. > > Also - Aymeric - you've done a great job with this app loading work. I > didn't get much of a chance to follow along as it was unfolding, but the > resultant work has been a pleasure to work wi

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 check framework > registra

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

major problems. Also - Aymeric - you've done a great job with this app loading work. I didn't get much of a chance to follow along as it was unfolding, but the resultant work has been a pleasure to work with. With one exception :-) We've now got AppConfig objects for each app (e.g., c

Re: App-loading reloaded

gt; my best to document. Early testing will be critical for the success of 1.7. >>> Try your projects with the current master of Django, or with 1.7 alpha when >>> it’s released at the end of the month, and let me know if you run into >>> trouble. >>> >>> ** Not

Re: App-loading reloaded

gt; my best to document. Early testing will be critical for the success of 1.7. >>> Try your projects with the current master of Django, or with 1.7 alpha when >>> it’s released at the end of the month, and let me know if you run into >>> trouble. >>> >>&

Re: App-loading reloaded

Django, or with 1.7 alpha when >> it’s released at the end of the month, and let me know if you run into >> trouble. >> >> ** Not done ** >> >> 5) Allow changing db_prefix >> - I agree with the “wontfix” of #891 >> 8) Provide APIs to disc

Re: App-loading reloaded

o discovery is a bad idea in general - Django shouldn't > import random modules! > - app_config.path seems good enough for filesystem discovery > (doesn’t work in eggs, though) > 9) AppAdmin — #7497 > - app-loading provides slightly more firm foundation for

Re: App-loading reloaded

y is a bad idea in general - Django shouldn't import random modules! - app_config.path seems good enough for filesystem discovery (doesn’t work in eggs, though) 9) AppAdmin — #7497 - app-loading provides slightly more firm foundation for this feature - it's a

Re: App-loading reloaded

se of you further east!! > I know that I didn’t reach the standards of communication and quality > expected in the Django community while I was working on this project. I > didn’t try to have a discussion on this mailing list. I asked a few core devs > who worked on app-loading in the p

Re: App-loading reloaded - running code at startup

I'd also suggest that the ORM is only disallowed until such as time as the models are set up - we require Queryset creation at module level in forms for example. Obviously your models.py should not import your forms.py, but that's another issue. On 31 December 2013 10:31, Anssi Kääriäinen wrote:

Re: App-loading reloaded - running code at startup

On 12/31/2013 12:13 PM, Aymeric Augustin wrote: On 31 déc. 2013, at 10:40, Anssi Kääriäinen wrote: Another solution is to prevent generation of QuerySets before models are fully loaded. I think Django does that since I removed the re-entracy hack in Apps.populate(). get_models() now raises

Re: App-loading reloaded - running code at startup

On 31 déc. 2013, at 10:46, Anssi Kääriäinen wrote: > A question: what happens if you have multiple name = "django.contrib.auth" > AppConfigs in your project? https://code.djangoproject.com/ticket/21679 :-) -- Aymeric. -- You received this message because you are subscribed to the Google Gro

Re: App-loading reloaded - running code at startup

On 31 déc. 2013, at 10:40, Anssi Kääriäinen wrote: > Another solution is to prevent generation of QuerySets before models are > fully loaded. I think Django does that since I removed the re-entracy hack in Apps.populate(). get_models() now raises an exception until all models are fully loaded,

Re: App-loading reloaded - running code at startup

On 12/30/2013 11:05 PM, Aymeric Augustin wrote: On 30 déc. 2013, at 21:59, Marc Tamlyn > wrote: On another note, if you're going to muck about with a model in an existing app (perhaps for a very good reason like Permission) the best way of doing that (IMO) would b

Re: App-loading reloaded - running code at startup

On 12/31/2013 10:54 AM, Aymeric Augustin wrote: On 31 déc. 2013, at 05:41, Daniel Lindsley wrote: On Problem #1, IMO, I'd prefer to see something akin to an ``AppConfig.setup`` (before anything is imported or built) & an ``AppConfig.complete`` (after all classes have been setup for the

Re: App-loading reloaded - running code at startup

On 12/31/2013 10:41 AM, Aymeric Augustin wrote: On 31 déc. 2013, at 04:28, Russell Keith-Magee mailto:russ...@keith-magee.com>> wrote: On Mon, Dec 30, 2013 at 8:29 PM, Aymeric Augustin > wrote: Logically, this would get called when the app cache

Re: App-loading reloaded - running code at startup

On 12/30/2013 10:10 PM, Anssi Kääriäinen wrote: First, a big +1 for improved app-loading sequence. Problem 2: my vote for solution 2.b. This seems to be the most reliable way. Quick throwaway scripts will need two more lines of boilerplate code but that is easily worth the added reliability

Re: App-loading reloaded - running code at startup

On 31 déc. 2013, at 05:41, Daniel Lindsley wrote: > On Problem #1, IMO, I'd prefer to see something akin to an > ``AppConfig.setup`` (before anything is imported or built) & an > ``AppConfig.complete`` (after all classes have been setup for the app). I > think this would make it clearer as

Re: App-loading reloaded - running code at startup

On 31 déc. 2013, at 04:28, Russell Keith-Magee wrote: > On Mon, Dec 30, 2013 at 8:29 PM, Aymeric Augustin > wrote: > > Logically, this would get called when the app cache is fully populated. > Running user code while the app cache isn’t ready will backfire. > > But at this point it’s too lat

Re: App-loading reloaded - running code at startup

Aymeric, Your work is amazing and has improved Django so much. Your work on timezone support, the transaction overhaul and now this app changes makes my and a lot of other peoples experience with Django so much better. Thank you! 2013/12/30 Aymeric Augustin > ## Solution 2.a — Require users to

Re: App-loading reloaded - running code at startup

Aymeric, As with the others, I'd like to echo my thanks! Having spent a lot of time with the old AppCache, I think these are solid improvements. Just a couple thoughts/questions from me. On Problem #1, IMO, I'd prefer to see something akin to an ``AppConfig.setup`` (before anything i

Re: App-loading reloaded - running code at startup

Hi Aymeric, First off - a *huge* thanks for all the work your doing on app reloading. I can't begin to express how much gratitude I have for the work you're doing here. On Mon, Dec 30, 2013 at 8:29 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > There’ve been lots

Re: App-loading reloaded - running code at startup

Heh, I forgot that contribute to class isn't documented. On second thoughts, let's not document this unless we actually have a good API for it. On 30 Dec 2013 21:05, "Aymeric Augustin" wrote: > On 30 déc. 2013, at 21:59, Marc Tamlyn wrote: > > On another note, if you're going to muck about with

Re: App-loading reloaded - running code at startup

On 30 déc. 2013, at 21:59, Marc Tamlyn wrote: > On another note, if you're going to muck about with a model in an existing > app (perhaps for a very good reason like Permission) the best way of doing > that (IMO) would be to create a subclassed AppConfig, get the relevant model > from Apps in t

Re: App-loading reloaded - running code at startup

On 30 déc. 2013, at 21:51, Marc Tamlyn wrote: > doing away with the magical "I created a Model subclass and my app registry > hot populated" issues. > This is ModelBase.__new__, another scary beast I haven’t attacked yet :) -- Aymeric. -- You received this message because you are subscribed

Re: App-loading reloaded - running code at startup

settings with app configs. > > Marc > On 30 Dec 2013 20:10, "Anssi Kääriäinen" wrote: > >> First, a big +1 for improved app-loading sequence. >> >> Problem 2: my vote for solution 2.b. This seems to be the most reliable >> way. Quick throwaway scripts w

Re: App-loading reloaded - running code at startup

: Are model imports going to be allowed > from app modules? I believe allowing this will cause problems later on. > > If app-loading and model loading happens in mixed order (due to model > imports in app modules launching model loading for the imported models), > then there could be p

Re: App-loading reloaded - running code at startup

in the documentation but not going an extra mile to support or prevent it. > If app-loading and model loading happens in mixed order (due to model imports > in app modules launching model loading for the imported models), then there > could be project initialization differences depending

Re: App-loading reloaded - running code at startup

First, a big +1 for improved app-loading sequence. Problem 2: my vote for solution 2.b. This seems to be the most reliable way. Quick throwaway scripts will need two more lines of boilerplate code but that is easily worth the added reliability. I have a question about problem 1: Are model

Re: App-loading reloaded - running code at startup

On 30 déc. 2013, at 17:37, Ryan Hiebert wrote: > It's probably obvious to others, but where would that `django.setup()` be? import django django.setup() Since setup() couples django.apps and django.conf, putting it into the django package seemed appropriate. -- Aymeric. -- You received thi

Re: App-loading reloaded - running code at startup

Op maandag 30 december 2013 17:16:21 UTC+1 schreef Aymeric Augustin: > > On 30 déc. 2013, at 13:29, Aymeric Augustin > > > wrote: > > [...] > > The real question — is requiring django.setup() acceptable? Explicit is > better than implicit, after all… > > As far as I can see only people who l

Re: App-loading reloaded - running code at startup

On Mon, Dec 30, 2013 at 10:16 AM, Aymeric Augustin wrote: > The real question — is requiring django.setup() acceptable? Explicit is > better than implicit, after all… It's probably obvious to others, but where would that `django.setup()` be? -- You received this message because you are subscr

Re: App-loading reloaded - running code at startup

On 30 déc. 2013, at 13:29, Aymeric Augustin wrote: > ## Solution 2.a — Require users to call django.setup() before they use the > ORM. setup() would configure the settings and populate the app registry. > (…) > I’m currently working on this and I’ll add a commit to the pull request > (which I’

App-loading reloaded - running code at startup

Hello, There’ve been lots of brainstorming on this topic. It is now tracked in this ticket: https://code.djangoproject.com/ticket/21676. I’ve also sent a pull request: https://github.com/django/django/pull/2128. There’s a consensus on the general idea: - AppConfigs are a good place for startup

Re: App-loading reloaded

Hello, Here’s an final update on the remaining items in my TODO list. If there’s anything you want to discuss, please start a new thread, as this one is just an long monologue designed to keep a public record of what I’ve been doing. On 26 déc. 2013, at 22:47, Aymeric Augustin wrote: > I sti

Re: App-loading reloaded

> ticket is a nuisance. Done. See https://code.djangoproject.com/query?status=!closed&keywords=~app-loading. > ** Cleanup / small tasks ** > > * Rename AppCache to InstalledApps? Then we should also replace app_cache by > installed_apps. Originally proposed by Arthur Koziel.

Re: App-loading reloaded

On 26/12/13 11:47, Aymeric Augustin wrote: > On 26 déc. 2013, at 00:22, Luc Saffre wrote: > >> But your implementation is more beautiful than mine, and I'm looking >> forward to retire my djangosite project as soon as possible. > > I wouldn’t say “beautiful” as much as “minimal”. Django’s core m

Re: App-loading reloaded

Hi Luc, On 26 déc. 2013, at 00:22, Luc Saffre wrote: > On 24/12/13 12:23, Aymeric Augustin wrote: > >> Of course I’m happy to provide feedback and supervision to >> contributors who’d like to tackle some of these items. Just get in >> touch before you start coding to avoid duplicate work. > >

Re: App-loading reloaded

On 24/12/13 12:23, Aymeric Augustin wrote: > > Of course I’m happy to provide feedback and supervision to > contributors who’d like to tackle some of these items. Just get in > touch before you start coding to avoid duplicate work. Hey Aymeric, thanks for your work! I am not a core developer, but

Re: App-loading reloaded

On 23 déc. 2013, at 23:31, Andrew Godwin wrote: > The big question is, of course, how feasible is it that this will all* land > by the alpha? It's January 20th - less than a month away - and while I'd like > to see this land in 1.7, if it misses that date it's out; the release is > already com

Re: App-loading reloaded

solution doesn’t use signals, as there is no > earlier opportunity to register them. > > I know that I didn’t reach the standards of communication and quality > expected in the Django community while I was working on this project. I > didn’t try to have a discussion on this mailing list. I

Re: App-loading reloaded

list. I asked a few core devs who worked on app-loading in the past to look at my code and ruthlessly pushed it as soon as I got their feedback. Given the staggering amount of hard problems I was trudging though, that’s all I could manage, and it was a conscious choice. Now that master has

Re: App-loading reloaded - custom app names in the admin

>>> >>>> INSTALLED_APPS = [ >>>> # … >>>> 'myproject.apps.GypsyJazzConfig', >>>> # … >>>> ] >>>> >>>> The class can live anywhere, but it must provide a “name” so that Django >>>> kn

Re: App-loading reloaded - custom app names in the admin

relates to. >>> >>> Notes for reviewers >>> >>> There’s one part of the patch I don’t like much: the AppCache methods >>> listed under ### DANGEROUS METHODS ###. I’ve made it very obvious that >>> they’re private APIs and they’re only used in t

Re: App-loading reloaded - custom app names in the admin

ping the >> details as I’m afraid they would add more confusion than clarity. >> >> Day 6 >> >> I began laying the ground for AppConfig classes in INSTALLED_APPS by >> searching a way to remove all direct references to INSTALLED_APPS to use >> app_ca

Re: App-loading reloaded - custom app names in the admin

PS didn’t. This may result in different > behavior, including import loops, but I’m afraid there’s no way around this. > Hopefully the end result will be more deterministic than what we currently > have, as Django will populate the app cache earlier. > > I don’t know how I’

App-loading reloaded - custom app names in the admin

dozen of these in the test suite. Until now I’ve refrained from implementing AppCache.reload() because it means https://code.djangoproject.com/attachment/ticket/3591/app-loading.2.diff#L165 and that scares me. I might end up reusing AppCache.set_available_apps(), although currently it only suppor

Re: App-loading reloaded - apps without a models module

On 16 déc. 2013, at 12:02, Aymeric Augustin wrote: > I sent a pull request implementing my first goal: > https://github.com/django/django/pull/2076. Merged: https://github.com/django/django/compare/fe1389e911b0...4a56a93cc458 -- Aymeric. -- You received this message because you are subs

App-loading reloaded - apps without a models module

today: https://github.com/aaugustin/django/tree/yet-another-app-loading-branch [1] https://code.djangoproject.com/attachment/ticket/3591/app-loading.2.diff [2] https://github.com/ptone/django/compare/master...app-loading Day 2 Yesterday I replaced all direct calls to the get_app, get_model, etc

  1   2   >