Merge request I sent a pull request implementing my first goal: https://github.com/django/django/pull/2076. It allows creating apps without a models module, and that’s it. As far as I can tell it’s fully backwards-compatible. It even includes deprecation paths for some private APIs for extra safety.
It was reviewed by Florian Apolloner and Marc Tamlyn. They had some suggestions which I implemented and they gave it a +1. It was tested by Loic Bistuer. He found a small issue with migrations which I fixed. I want to merge it soon because it contains huge refactorings that could go stale. Since it has some overlap with Andrew’s work on migrations, it’s safer to perform continuous integration by merging to master often. I haven’t written documentation yet. It’s just a matter of removing all suggestions that Django apps must contain a models module and adding an entry in the release notes. I’ll do that in time for 1.7 alpha. Even if failed to reach my other goals, this patch would be worth merging because it improves the design of the app cache and paves the way for interesting features. If you see a good reason not to merge it, please tell me as soon as possible! Notes for reviewers Here’s a digest of the daily notes I sent to potential reviewers while I was working on this patch. Day 1 My priorities are backwards-compatibility, minimalism, and reviewability. I want something to be merged even if it’s just the first step in a series of incremental improvements. After spending some time studying Jannis’ and Preston’s latest patches [1] [2], sadly, I came to the conclusion that it would be inefficient for me to start by rebasing Preston’s branch on top of master. First, it’s quite outdated. Then, there’s just much code that I don’t understand to make rebasing a realistic option. Finally, some code was written to support goals that I’ve excluded from my scope, some is a work in progress, and some looks left over from previous iterations of the patch. I’m sorry. I’ll still try to extract as much value as I can from past efforts. My plan is to get to a minimal working solution with incremental changes, then review Preston’s diff to see if I’ve missed something interesting, and finally steal the tests and docs in bulk. I know that TDD would be cleaner but I don’t have enough motivation and time to do it that way. I started coding 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. functions by method calls on the app_cache object, in order to normalize the code base and make it more obvious when we’re relying on global state. I saw how pervasive our use of the app cache was, wept quietly and moved on. Today I created an AppConfig class. I gathered from past discussions that there was a consensus on this name. (“App” already means something else.) Then I refactored the app cache to store state in one AppConfig instance per application. I haven't introduced any changes in behavior — at least not knowingly. The code is too complicated for my tastes because Django allows using models from apps that aren’t in INSTALLED_APPS. I’ve known about this behavior for some time and I’m still wondering why we need it. I’d like to deprecate this possibility by raising a warning and then an exception when a model is imported from an app that isn’t in INSTALLED_APPS. But I’ll leave that for later in order to keep my branch backwards-compatible. I plan to continue to refactor code that uses the models module as a key. That means replacing all uses of app_cache.get_app(label), which returns a models module, by something that operates on an AppConfig instance. I will go as far as possible with 100% backwards-compatible refactoring before introducing changes. Day 3 Today I’ve introduced get_app_config() and get_app_configs() methods and refactored get_app() and get_apps() to use them. The first one was tricky because get_app() has grown some cruft over the years that doesn’t seem useful any more. I’ve written a detailed explanation in the commit message. I’ve then deprecated get_app_package(), get_app_path() and get_app_paths(). They were barely used. I’ve also simplified some parts of the app cache code. I broke the test suite countless times and it’s still broken right now. That’s good news, because it means that the existing tests go though many code paths in the app cache. I’m relying on that to validate my refactoring. Tomorrow I’ll make sure that the test suite passes after each commit. (I’m rewriting history heavily to keep the branch reviewable.) Then my next step will be to replace all uses of get_app() and get_apps() in Django and deprecate these two methods. All this aims at making the app cache code as tight as possible and at bringing it to a point where it’s trivial to provide full support for apps without models.py, with a small change in load_app(). Day 4 Today went pretty much as planned. I started by fixing the test suite and deprecating get_app() and get_apps(). Then I made it possible to create apps without a models module. The deprecated (pre-1.6) test runner relied heavily on models module; I refactored it in a separate commit for clarity. -- Aymeric. -- 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/816DF8A6-9811-4856-9089-4575EB02A861%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
