> > 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 [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.
