How to disable system check framework?

[Marcin Nowak]

Hi,

I need to upgrade project to Django 1.8 but the SystemCheck Framework bothers me.

It complains about thigs that should work, even if they are a little tricky.

I need to disable system checks designed for blogs and other simple sites. How can I do that?

Best Regards,

Marcin

[Carl Meyer]

The third paragraph of the system checks documentation [1] links to [2].

Also, this is a question about using Django, not developing Django, so it belongs on the django-users mailing list, not here.

Carl

[1] https://docs.djangoproject.com/en/1.8/topics/checks/
[2] https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS

[Marcin Nowak]

Thanks, Carl. I know about silencing but I want to disable unwanted "feature". Working with Django is getting harder with every new version. 

[Josh Smeaton]

Your "scare quotes" for "feature" are really disappointing. Especially considering that the checks were hardcoded and couldn't be silenced prior to the "system check framework".

> Working with Django is getting harder with every new version.

If you want to turn off new features or extension points, then I'd imagine there'd be more work than for the regular user. Otherwise, I couldn't disagree more.

Anyhow, you want to turn off system checks for some reason. Here are some potential ways forward:

- Target the checks that are incorrectly spitting out errors or warnings, and fix those.

- Provide another setting "DISABLE_CHECKS" or something similar that will prevent checks running altogether (probably not ideal, new settings are hard to get into core, especially when the benefit here is still questionable).

- Provide a special value for the existing SILENCED_SYSTEM_CHECKS setting that causes all checks to be silenced.

You haven't really said much about the issue other than it bothers you. The main purpose of checks are for development - so it doesn't have any runtime or deployment time penalties. Perhaps if you took some time to justify why users other than yourself might want to disable the check framework, it'd be easier to start looking at solutions to problems.

Cheers

[Marcin Nowak]

Thank, Josh.

I'm upgrading mature and complex project, which have some tricky parts implemented like a monkey-patched user model, which is applied after system chceck execution. So Django complains about missing fields in ModelAdmin, but patch works fine. There were some complains about doubled mappings to fields, but I've removed them. Generally speaking I don't need System Check, because I can find soultion myself other way.

Migrations are similar - they are too simple/limited for my needs. They operate on models, but I'm working mainly with database and I'm creating mappings for tables and views for easy querying. So I don't need builtin migrations feature.

I'm using commit_manually() frequently, but this decorator was removed... 

And so on...

That's why I feel that working with Django is harder. It's more strict, useful tools/helpers are missing, there is more features which should be bypassed/omitted. I feel that is harder to do simple things... Or maybe I'm getting old. ;)

Cheers,

Marcin

[Aymeric Augustin]

On 5 août 2015, at 11:09, Marcin Nowak <marcin....@gmail.com> wrote:

> I'm using commit_manually() frequently, but this decorator was removed...

Hi Marcin,

Sorry for derailing the discussion a bit, but could you clarify why you were
using this API? I removed it after failing to find a use case where it would
be preferrable to commit_on_success(). I’d love to know if I missed something
in order to avoid making similar mistakes again.

Using commit_manually() properly required great care -- and a try/finally
construct in practice -- to ensure that no code path escaped without a commit
or a rollback. It also required a massive amount of boilerplate to avoid
masking exceptions:

- https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J
- https://code.djangoproject.com/ticket/6623

If you replace it with transaction.atomic() and remove the boilerplate, you
get the same behavior with ten times less code.

In case removing the boilerplate creates too much code churn, I documented a
real drop-in replacement that doesn't have the drawbacks of commit_manually:
https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5

What could I have done better?

If you don't want any changes in Django -- your posts to this list are often
after-the-fact complains about new features -- perhaps you could stick with
whatever version of Django you're currently running?

--
Aymeric.

[Marcin Nowak]

Hi Aymeric,

This project is complex, as I said before, and works well with Django 1.4. But we need to upgrade it to newer version because of lack of support, security issues, and simplifcation of maintenance and growth (we're currently using three different Django versions, from 1.4 to 1.7, and we've decided to upgrade all subprojects to 1.8)

commit_manually() is used within long-live processes running as a mgmt commands, where is used multiprocessing too.

Whole process is complicated and hard to maintain. I would like to avoid logical / flow changes, whose are required to replace commit_manually() with atomic().

Second use case is a extract-transform-load subsytem, which also requires precise development of queries, commits and rollbacks. I'm afraid that upgrade of it may be also hard.

I think that there are rare cases, when manual transaction handling is required and should be available for punctilious developer.

BUT I can't say that atomic() does not fit my needs. I know how it work (I belive), but it may not cover current cases (implementation).

I must try to do replacement or bring old behaviour of commit_manually() with my custom wrapper. I'm trying to change code as less as possible.

You're asking what could be done better.. Generally speaking - an API compatibility layer. As a maintainer of big and old project I would like to import "commit_manually" from special module delivered with Django, which will guarantee stability and compatibility. This may be even undocumented. Manual commit() and rollback() functions are provided in transaction module (thanks so much for that!), so making compat layer should be possible, I think.

Kind Regards,

Marcin

[Carlton Gibson]

Sorry to be a pain but, could this thread be continued (if it's going to be) on Django Users?

(sorry)

—

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3257c139-f52e-422f-8eb4-5a97771ca367%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marcin Nowak]

It's ok. I think that the thread can be closed, except the suggestion of making compatibility layer, which is rather a kind of Django`s philosophy and may be continued in a new thread (if needed).

[Florian Apolloner]

On Wednesday, August 5, 2015 at 3:59:39 PM UTC+2, Marcin Nowak wrote:

<snip>

I must try to do replacement or bring old behaviour of commit_manually() with my custom wrapper. I'm trying to change code as less as possible.

To be honest the "issues" you outlined here seem to suggest a bigger problem within your own code. I am aware that it is really hard and annoying to change from old style transactions to the new ones in big projects, but given the fact that atomic() just works and I have yet to see a project which used old style transactions properly (see Aymerics presentation on transactions), I think it is worth it.
 

You're asking what could be done better.. Generally speaking - an API compatibility layer. As a maintainer of big and old project I would like to import "commit_manually" from special module delivered with Django, which will guarantee stability and compatibility.

And defer upgrading to a proper transaction management for another few years? Seriously, if your project is to big to upgrade stick with 1.4 and use a distribution which provides LTS support for it (but yes, ultimately you will have to switch, but from what I hear Redhat is going to support 1.4 for another while :D)=…

Cheers,
Florian

[Marcin Nowak]

No, there is not problem in this code only, but yeah - it is a big problem. Real problem is that newer versions of Django are pushing developers to do things by the only one way, which is good for blogs or cms, or maybe new and small projects. As the result it is getting harder to maintain complex project based on Django unless you stay with old-and-unsupported version. And I'm not talking about atomic(), which is good and simple.

> And defer upgrading to a proper transaction management for another few years?

No. Just provide old-style wrappers (at the python-level api compatibility) for old guys maintaining old projects ;)

I can say something similar about generics views based on CBV - function based wrappers can be built top of CBV and can be provided in django.compat or django.legacy package. Just suggesting.

 

Cheers,

Marcin

[Tim Graham]

If you have a big need to use old APIs, feel free to implement them in your own package or even in a reusable app so that others can benefit too. There have been other efforts like https://github.com/arteria/django-compat to do so. We can't maintain them forever, lest Django become bloated and difficult to maintain.

If you followed the discussion about the new deprecation policy, you'll know that we are trying to make it easier to upgrade from one LTS to the next, but some things are inevitably going to change or be removed in an effort to improve Django. You can help us by testing preleases and giving feedback before final releases.

[Aymeric Augustin]

Hi Marcin,

Thanks for the clarification, that's helpful.

The backwards compatibility wrapper looks like this in this case:

@contextlib.contextmanager

def commit_manually(using=None):

    transaction.set_autocommit(False, using)

    try:

        yield

    finally:

        transaction.set_autocommit(True, using)

(typed on a phone and not tested)

We recently decided against shipping compatibility wrappers with Django because the interaction with the deprecation policy is messy. However, like Tim said, we're trying to make it easier to have such wrappers.

-- 

Aymeric.

[Tim Graham]

Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods so they are applied before the system check framework is invoked? Model and admin validation were part of Django 1.4 too, by the way.

How many problematic checks are you running into? Can you describe them a bit more? If anything, SILENCED_SYSTEM_CHECKS = ['*'] to disable checks seems like the best option that Josh proposed, but I'd like more justification before we spend time doing that.

Does anyone else have a desire to completely disable system checks?

[Marcin Nowak]

On Thursday, August 6, 2015 at 5:36:09 PM UTC+2, Tim Graham wrote:

Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods so they are applied before the system check framework is invoked?

I'll try that, thanks. To be honest I should remove monkeypatching, I don't like it, but I don't want do it now.

 

 

How many problematic checks are you running into?

Above 60 overall.

Can you describe them a bit more? If anything, SILENCED_SYSTEM_CHECKS = ['*'] to disable checks seems like the best option that Josh proposed, but I'd like more justification before we spend time doing that.

E108, E304, E305, E116, E306, many W342, W340.

I'm using many mappings for read-only and they don't need to be valid as regular models.

Cheers,

Marcin

[Marcin Nowak]

Thanks for the snippet, Aymeric! I've found similar on Gist, but yours seems to be better. Thanks.

Marcin

[Tim Graham]

Could you elaborate on why disabling system checks entirely is better than selectively disabling checks that are problematic for you? Is it really never helpful? If there are more people clamoring for this feature, I think I'd be more open to it.

SILENCED_SYSTEM_CHECKS = ['admin.E108', 'admin.E304', 'fields.E305', 'admin.E116', 'fields.E306', 'fields.W342', 'fields'W340']

[Marcin Nowak]

Tim,

They aren't really silenced, but skipped. I would like to silence them for real. They are skipped, but still printed out.

Let's assume that I am a guy who wants to silence every system check. I need to list ALL errors and warnings, which is:

  * unhandy and it would require maintain a big list (especially after upgrading Django to newer version)

  * messages are still visible (I don't need them and I don't want to read them, and any other developer don't want to read them)

  * django bootstraping is still slower due to executing system checks.

As an old-and-experienced-guy I want to disable (completely) system checks on my responsibility. 

Just belive me - I know what I'm doing. And I don't want to hack Django to do any non-typical things.  

Why you can't add just one setting to bypass something which is currently built-in? Is that a really big problem?

[Carl Meyer]

Hi Marcin,

On 08/11/2015 10:44 AM, Marcin Nowak wrote:
> They aren't really silenced, but skipped. I would like to silence them
> for real. They are skipped, but still printed out.

I'm not sure what you're referring to here. If you include a system
check warning code in the SILENCED_SYSTEM_CHECKS setting, as far as I'm
aware that warning is completely silenced, and is not printed anywhere.
If you think otherwise, you'll need to provide a specific example.

> Let's assume that I am a guy who wants to silence every system check.

We can assume that, but it doesn't provide an argument for anything
unless you can make a reasonable case for _why_ you want to do that, and
some evidence that other people also may want to do the same thing
(these two are connected). So far I don't see either.

> I
> need to list ALL errors and warnings, which is:
> * unhandy and it would require maintain a big list (especially after
> upgrading Django to newer version)

That's a good reason not to include this "feature." How can you say now
that a check included in a future Django version won't be relevant to
you or catch a bug in your code, when you don't even know yet what that
check is?

We don't add checks just for the fun of it -- we add them when we have
good evidence that something is likely to be an error in many people's
codebases. Such checks should be silenced when you understand the
specific error and understand why it's not relevant in your unusual
case. There's no way that you can make such an assertion about all
possible future checks.

> * messages are still visible (I don't need them and I don't want to
> read them, and any other developer don't want to read them)

I don't think this is true.

> * django bootstraping is still slower due to executing system checks.

This isn't relevant unless you have profiling data showing a noticeable
difference in a realistic use case.

> As an old-and-experienced-guy I want to disable (completely) system
> checks on my responsibility.
> Just belive me - I know what I'm doing. And I don't want to hack Django
> to do any non-typical things.

Why not? Isn't "I've hacked Django to do lots of non-typical things" the
basis of your desire to disable system checks? So what's wrong with one
more?

> Why you can't add just one setting to bypass something which is
> currently built-in? Is that a really big problem?

Because every new setting is a new conditional path that has to be
tested, and the interaction of every other feature with that new
conditional path is now in theory a possible bug location. In other
words, a single new boolean setting doubles the total number of possible
configurations of Django that might contain a bug and need testing.

All new code is a maintenance burden, and requires stronger
justification than "one person said they wanted it."

All that said, if we do this, it should be spelled
`SILENCED_SYSTEM_CHECKS = ['*']`. I don't think there is ever a good
case for using it, and I think users who don't understand how
SILENCED_SYSTEM_CHECKS works may be tempted to use it to "just make the
errors go away", but all in all I'm still only -0.5.

Carl

[Shai Berger]

Hi all,

On Tuesday 11 August 2015 19:05:26 Carl Meyer wrote:
> On 08/11/2015 10:44 AM, Marcin Nowak wrote:
> > I need to list ALL errors and warnings, which is:
> > * unhandy and it would require maintain a big list (especially after
> > upgrading Django to newer version)
>
> That's a good reason not to include this "feature." How can you say now
> that a check included in a future Django version won't be relevant to
> you or catch a bug in your code, when you don't even know yet what that
> check is?
>

Further -- the cheks framework allows your apps or 3rd-party apps to add
checks of their own. So, the above argument also multiplies to all future
versions of all apps you use.

>
> All that said, [...] I think users who don't understand how

> SILENCED_SYSTEM_CHECKS works may be tempted to use it to "just make the
> errors go away", but all in all I'm still only -0.5.
>

FWIW, I'm -1.

I could be supportive of a --without-system-checks flag, which I can see useful
during development ("I know there's a problem here, I want to solve something
else first"). This would imply that a user needs to decide, every run anew,
that they don't want the checks. I'm aware that a user like Marcin could just
use an alias, or change their manage.py, to have the flag included
automatically; I'd take a "consenting adults" approach towards that sort of
abuse.

Shai.

[Adam Johnson]

Marcin - you can "tidy up" some monkey patches, or at least make them robust to the code you're replacing changing, by using https://github.com/adamchainz/patchy .

I'm -1 - we've recently been implementing project system checks for our team and they are super useful. We even have one that checks if requirements.txt has been updated since the virtual environment was created. It would be bothersome if there was a way for developers to disable *all* checks for themselves. Also whilst many 3rd-party apps are adding checks recently, you don't want to miss out on the help they provide.

[Marcin Nowak]

Thanks for replies, Carl, Adam, Shai.

But I think you're worrying too much for too many things. You're trying to control everything, trying to replace automated tests with system check framework, trying to block "invalid" operations, etc, etc. This is bad way, IMO.

 

Let's see a small example how system check framework works:

1. I'm adding custom field to user (by patching User models, don't ask why - other ways does not work)

class MyAppConfig(AppConfig):

    name = 'my app'

    def ready(self):

        from django.contrib.auth.models import User

        from django.db import models

        User.add_to_class('is_verified', models.BooleanField(default=False))

2. I'm adding new field to admin interface

@admin.register(User)

class MyUserAdmin(UserAdmin):

[...]

    list_filter = ('is_superuser', 'is_active', 'is_verified')

[...]

3. Django raises an error:

ERRORS:

<class 'myapp.admin.MyUserAdmin'>: (admin.E116) The value of 'list_filter[2]' refers to 'is_verified', which does not refer to a Field.

Which is not true!

4. I'm silencing E116:

SILENCED_SYSTEM_CHECKS = ['admin.E116']

5. Django starts, admin works  (and new filter works also), but runserver still prints out a false message:

Performing system checks...

System check identified some issues:

ERRORS:

<class 'myapp.admin.MyUserAdmin'>: (admin.E116) The value of 'list_filter[2]' refers to 'is_verified', which does not refer to a Field.

I know that this is unbelievable, Carl, but the message is displayed!

And prints out untrue message at all...

Sorry, but this is not helpful...

BR,

Marcin

[Aymeric Augustin]

Hello Marcin,

There’s an obvious bug here: silenced checks are still printed out — even though they don’t prevent Django from starting.

I hadn’t understood that from your earlier messages. It shouldn’t be very hard to fix.

If you want to make sure we don’t lose track of this bug, you should file a ticket.

-- 

Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7fef0c25-2706-4072-86d9-ca3e0dbc03c6%40googlegroups.com.

[Tim Graham]

It seems this was an intentional design decision as the documentation states, "Silenced warnings will no longer be output to the console; silenced errors will still be printed, but will not prevent management commands from running." I guess it could/should be revisited?

https://docs.djangoproject.com/en/1.8/ref/settings/#silenced-system-checks

[Carl Meyer]

Hi Ma

On 08/25/2015 07:46 AM, Marcin Nowak wrote:
> Thanks for replies, Carl, Adam, Shai.
>
> But I think you're worrying too much for too many things. You're
> trying to control everything, trying to replace automated tests with
> system check framework, trying to block "invalid" operations, etc,
> etc. This is bad way, IMO.
>
> Let's see a small example how system check framework works:
>
> 1. I'm adding custom field to user (by patching User models, don't
> ask why - other ways does not work)
>
> class MyAppConfig(AppConfig): name = 'my app'
>
> def ready(self): from django.contrib.auth.models import User from
> django.db import models
>
> User.add_to_class('is_verified', models.BooleanField(default=False))
>
> 2. I'm adding new field to admin interface
>
> @admin.register(User) class MyUserAdmin(UserAdmin): [...] list_filter
> = ('is_superuser', 'is_active', 'is_verified') [...]
>
> 3. Django raises an error:
>
> ERRORS: <class 'myapp.admin.MyUserAdmin'>: (admin.E116) The value of
> 'list_filter[2]' refers to 'is_verified', which does not refer to a
> Field.
>
> Which is not true!

I think likely the root problem here is that your monkeypatch is in a
module which is not imported when validation runs. If I were you, I'd
make sure that your `admin.py` imports whatever module does the
monkeypatching, and then I'd expect this error to go away.

> 4. I'm silencing E116:
>
> SILENCED_SYSTEM_CHECKS = ['admin.E116']
>
> 5. Django starts, admin works (and new filter works also), but
> runserver still prints out a false message:
>
> Performing system checks...
>
> System check identified some issues:
>
> ERRORS: <class 'myapp.admin.MyUserAdmin'>: (admin.E116) The value of
> 'list_filter[2]' refers to 'is_verified', which does not refer to a
> Field.
>

> I know that this is unbelievable, Carl, but the message *is
> displayed!* And prints out untrue message at all...

Yes, I guess it is by design that errors (as opposed to warnings) are
still printed even if "silenced". I didn't realize that - I guess I've
never tried to silence a system check error, just warnings.

That seems like a bad design decision to me, and I think we should
change it. Silenced should mean silenced.

Carl

[Marcin Nowak]

On Tuesday, August 25, 2015 at 3:59:20 PM UTC+2, Aymeric Augustin wrote:

There’s an obvious bug here: silenced checks are still printed out — even though they don’t prevent Django from starting.

I hadn’t understood that from your earlier messages. It shouldn’t be very hard to fix.

Don't worry, it may come from my poor english skills.

 

If you want to make sure we don’t lose track of this bug, you should file a ticket.

Well, I'm not sure now, because Tim wrote that it was a design decision and it is well documented.

I would like to turn off system checker, live without it, and rely on my automated tests only. This should be simplest solution for uncommon cases, and should be simple to implement without design change.

Also please note that silencing specific errors is not the best solution. 

In the first case E116 may be untrue and may be silenced, but for other models this error may be true and shouldn't be silenced at all.

Silencing all E116 will give us messy information about state.

BR,

Marcin

[Carl Meyer]

On 08/25/2015 08:57 AM, Marcin Nowak wrote:
> Well, I'm not sure now, because Tim wrote that it was a design decision
> and it is well documented.

I still think we should change that design. It is simply wrong to have a
setting called `SILENCED_SYSTEM_CHECKS` that fails to actually _silence_
the check IDs listed.

> Also please note that silencing specific errors is not the best solution.
> In the first case E116 may be untrue and may be silenced, but for other
> models this error may be true and shouldn't be silenced at all.
> Silencing all E116 will give us messy information about state.

That's why I think in this case the best solution is to actually fix the
error, not silence it; Django should be able to find a find a field even
if it's monkeypatched-in, as long as the monkeypatch happens in time.

Carl

[Marcin Nowak]

On Tuesday, August 25, 2015 at 4:51:51 PM UTC+2, Carl Meyer wrote:

I think likely the root problem here is that your monkeypatch is in a
module which is not imported when validation runs. If I were you, I'd
make sure that your `admin.py` imports whatever module does the
monkeypatching, and then I'd expect this error to go away.

Yes, Django does not "know" about patched user in a validation stage.

I will try to change it, but this is an example only.

 

PS. I would like to avoid any monkey patches, hacks, and just omit obstacles. :)

Django is a good (the best?) web framework for rapid development, but sometimes is a part of a bigger stack. 

In that case some unnecessary Django`s limitations/forcings may be problematic to maintain whole projects.   

BR,

Marcin

[Carl Meyer]

On 08/25/2015 09:15 AM, Marcin Nowak wrote:
> PS. I would like to avoid any monkey patches, hacks, and just omit
> obstacles. :)

I agree. In this case, you should use a custom User model instead of
monkey-patching User, but you asked us not to discuss that question :-)

Carl

[Marcin Nowak]

I think likely the root problem here is that your monkeypatch is in a
module which is not imported when validation runs. If I were you, I'd
make sure that your `admin.py` imports whatever module does the
monkeypatching, and then I'd expect this error to go away.

Yes, Django does not "know" about patched user in a validation stage.

I will try to change it, but this is an example only.

 

Thanks, Carl. This specific error can solved by changing 'django.contrib.admin' to 'django.contrib.admin.apps.SimpleAdminConfig' in INSTALLED_APPS.

BR,

Marcin

[Florian Apolloner]

On Tuesday, August 25, 2015 at 6:19:44 PM UTC+2, Marcin Nowak wrote:

Thanks, Carl. This specific error can solved by changing 'django.contrib.admin' to 'django.contrib.admin.apps.SimpleAdminConfig' in INSTALLED_APPS.

This disables admin autodiscovery though, I doubt that is what you want…

[Florian Apolloner]

I think the fix for you currently is to put __your__ app before the admin app, this way your ready() will patch the user first and then the admin checks run.

[Florian Apolloner]

Ups, not enough coffee yet, the admin.ready() just registers the checks, it does not execute them, so order should not matter -- I shall close my browser now and get some coffee :D

[Marcin Nowak]

On Wednesday, August 26, 2015 at 9:08:16 AM UTC+2, Florian Apolloner wrote:

Ups, not enough coffee yet, the admin.ready() just registers the checks, it does not execute them, so order should not matter -- I shall close my browser now and get some coffee :D

I don't know how exactly order of ready() calls is changing. After switching to SimpleAdminApp the order was changed. Why? I don't know, but it works. 

This disables admin autodiscovery though, I doubt that is what you want… 

I have a call for admin.autodiscover() in my urls, so there is no difference (?). I don't see any...

BR,

Marcin

[Tim Graham]

I created a ticket and pull request for the silencing of error/critical messages:
https://code.djangoproject.com/ticket/25318#ticket
https://github.com/django/django/pull/5197

[Marcin Nowak]

On Thursday, August 27, 2015 at 3:09:06 PM UTC+2, Tim Graham wrote:

I created a ticket and pull request for the silencing of error/critical messages:
https://code.djangoproject.com/ticket/25318#ticket
https://github.com/django/django/pull/5197

Thanks, Tim!

Marcin.

 

[Malcolm Box]

At the risk of re-opening this thread, I have just run into a very similar situation (see https://code.djangoproject.com/ticket/25374) and find that having the errors printed to the console is actually helpful - as I've had to silence errors to get the correct code to run, seeing if there's any *other* errors being "accidentally" silenced is helpful.

It seems there's actually two behaviours being conflated in "SILENCE_SYSTEM_CHECKS":

* Ignoring the error, so that the code will run (ie downgrade errors to warnings)

* Not printing the message

It's useful to be able to do the two things separately - I may want to downgrade an error because it's not one in my codebase, but still see if new instances of it creep in. Or I might want to not see any of a particular warning printed to the console.

Could we split this to:

IGNORED_SYSTEM_CHECKS

and 

SILENCED_SYSTEM_CHECKS

Malcolm