I've written four more tests. I've moved some of checks out of `__init__` methods. I've changed `tag` to `register`. I've rebased against master. I've improved documentation (added sections about filtering and silencing system checks), but I'm still polishing it. Code is ready for final review except for the issues I will mention in this post.
We probably cannot move checks of `primary_key` and `unique` living in `FileField.__init__`. We test if one of these two parameters was passed; we don't check their values. Consider that an user passes unique=False. This is the default value, but nevertheless, this should result in an error. We cannot check if the attributes where passed while performing system checks. I'm not sure if I make myself clear. We must reject fk/m2m to neither a model nor model name in `__init__`. Some pieces of code (i.e. `RelatedField.contibute_to_class`) assume that `self.to` is a Model or a string. 4. More important changes in code: >> - Introduced RAW_SETTINGS_MODULE [1]. I use it in compatibility checks to >> test >> if `TEST_RUNNER` setting was overriden [2]. > > Have a look at the internals of the diffsettings management command -- I'm > not sure RAW_SETTINGS_MODULE is needed. The problem is that when a test is decorated by `override_settings`, we need to test `settings._wrapped._wrapped`, otherwise we need to check `settings._wrapped`. 2. I'm afraid that there is too little time to merge django-secure. >> September 16 is >> suggested 'pencils down' date, so there are only less than two weeks (12 >> days) + >> one buffer week, because firm 'pencils down' date is September 23. Merging >> django-secure in such little time is actually impossible -- we must >> through out >> this task from schedule. I really apologize for that. > > This is obviously disappointing, but it's better to deliver something > complete than a half-attempt. If we can get the core framework into a good > state, merging django-secure is a self-contained task that we can address > as a follow-up commit. > Also -- the GSoC will come to an end, but that doesn't mean your > contributions to Django have to… :-) Sure. However, after merging I would like to focus on other kinds of contributing like reviewing tickets, replying on mailing list and so on) -- it's easy to get bored if you do the same job all the time. - Introduced `BaseAppCache.get_models_from_apps` method [3]. This method >> returns >> all models of given set of apps (or of all apps if None is passed) and >> is used >> in `default_checks.py` [4]. > > I'm not sure I follow why this is needed -- or why it isn't just > duplicating functionality from loading.get_models()? > `get_models(app=someapp)` let you get all models from *one* app. I notice that I sometimes need to get all models from a *set* of apps. I've just noticed that we need to implement `__str__` method for ModelAdmin *class* (not its instances) so errors involving ModelAdmins are printed correctly. I will work at that. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
