> > 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`. I and Russell agreed that this is not a huge problem since we can traverse through all "layers" of settings wrappers. However, there is another problem. By default, there are two settings file for tests: `django/conf/global_settings.py` and `tests/test_sqlite.py`. Settings from both files are mixed and indistinguishable. When no `override_settings` decorator is in use, there is only one 'layer' of settings. That means that we cannot test if `TEST_RUNNER` was overriden in `test_sqlite.py`. Any solutions? 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. We decided to use "applabel.ModelAdminClassName: (admin.E033) error message" style for ModelAdmin issues, so its `__str__` method should return "applabel.ModelAdminClassName". However, ModelAdmin class doesn't know which app defines it. That means it's impossible to implement its `__str__` method. Proposals: (1) Use ModelAdmin instances instead of the class as `obj` parameter to `Error` constructor. The drawback is that we need to pass also `site`. (2) Refactoring. Now ModelAdmin class does not know anything about model it references to (is it a design decision?). After refactoring, ModelAdmin will have the model attached to itself. (3) Hardcode that case in `CheckMessage.__str__` [1]. All three doesn't look like a good solution. [1] https://github.com/chrismedrela/django/blob/c010cd06619503b7d0db914c04c6ed58c69a9d9c/django/core/checks/messages.py#L35 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. > > > Why not just store a reference to the original arguments (or the relevant > subsets) in __init__(), and then validate them later in a system check? > That may seem a little indirect, but I think the validation system will be > much nicer if we can do everything in system checks instead of splitting > the work with __init__(). That's a good idea. Done in this commit [2]. [2] https://github.com/chrismedrela/django/commit/03fe680854b863020d865af5041172e4bd49943e -- 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.
