On Mon, Jul 15, 2013 at 8:17 PM, Christopher Medrela < [email protected]> wrote:
> Progress: I've implemented manager checks. > > The schedule for the next 4 weeks is: > > 1. Manager checks (ref 4.1.7)(done)(0.5 week). > 2. Entry point registering (ref 4.1.5) & rewriting mechanism of triggering > checking framework (ref 4.1.9)(1.5 week). > 3. Moving custom User model checks (ref 4.1.6)(0.5 week). > 4. Rewriting AdminModel checks and tests (ref 4.1.8)(1 week). > 5. Polishing doc (ref 4.1.10)(0.5 week). > > (ref 4.1.x are references to my original proposal [1]) > > [1] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129) > > Let's talk about public API to register your own validation stuff. There > will > be `register(callable)` function in `django.core.checks`. It will return > nothing. The callables will be stored in a global variable. They should > obey > the same contract as `check` methods: they allow for `**kwargs` and return > list of errors and warnings. All registered callables will be called during > checking phase (i. e. when you type `manage.py validate` or before running > server). > I think you're on the right track here. The only other viable approach I can think of would be a setting (SYSTEM_CHECKS) that is a list of functions to be invoked. However, this means installing a new app that contained a set of checks would mean modifying multiple settings (INSTALLED_APPS, SYSTEM_CHECKS, and possibly others for templates etc) This is also true of the registration approach -- the only difference is where you put the call to register. However, looking into the medium-term future, app refactor will eventually land, and at that point, we'll have a natural point to put all these registrations -- the app definition itself would be able to register the additional checks. To that end, I think a registration based approach will ultimately be better. And it isn't something that most users will be exposed to anyway -- all the pre-existing checks can be pre-registered, and admin can do it's registration as part of the autodiscover process. This API allows us to register, among other things, app-specific checks. But > it's not necessary to write an app in order to do some checks. > > `register` function will have two optional parameters: `run_in_production` > (default: False) and `run_in_development` (default: True) that let you > specify > when the callable should be called. Most checks should be performed only in > development environment (which is equivalent to DEBUG==True). Security > checks > makes sense only in production environment (<==> DEBUG==False). > > I would be happy if I could hear your opinion! > I don't think we need to worry about 'in production' level checks at time of registration. The default behaviour should always be to run all checks when ./manage.py check is invoked. There are some very specific checks (such as security checks) that only make sense in production, but they're the exception, not the rule. These checks could be skipped using a decorator when they're defined - essentially: def only_in_production(fn): def _dec(*args, **kwargs): if settings.DEBUG == False: return fn(*args, **kwargs) return [] return _dec @only_in_production def security_checks(…): … This decorator could be applied to the security check, so it becomes a no-op when it is executed in development. This can be determined by the check itself - I can't think of any circumstance where a user registering a check would need to have control over whether a check would be executed at all. Yours, Russ Magee %-) -- 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.
