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 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. For more options, visit https://groups.google.com/groups/opt_out.
