Any time the system check framework raises a warning that’s not relevant to you, you can turn off that warning.
1 Like
Being able to silence an incorrect alarm is nice. But not having an incorrect alarm sound in the first place seems better.
Do you have a use case in mind where someone would run makemigrations and a warning like I described above would be a false positive?
1 Like
shrug old projects updating to new Django versions are expected to make changes. We are not going to introduce special casing for stuff that we can already handle with the checks framework. And who says the alarm is incorrect – not having migrations nowadays seems worth having an alarm… Sure there might be special cases where you don’t want an alarm, so you can just disable the check.
3 Likes
In addition to what Florian said, Django already has the system-check framework as the standard single place to put these types of warnings. Adding one-off check/warning tooling to other parts of Django, just to work around the already-solved problem of turning off warnings someone doesn’t want to see, is not something I’d be in favor if.
4 Likes
It would also add overhead to the runserver startup. Overhead that would not exist in the alternative implementation as that code already has to check the existence of the folder to run.
I personally think the runserver overhead because of the checks running is already a bit of a problem.
You can runserver with --skip-checks if you need to save the time. I’m not sure what the behavior of makemigrations --skip-checks would be under your proposal for writing a check outside the checks framework.
My suggestion would be that it always writes the message. In my mind there are two situations:
A) you use migrations and you always want this message because if you get it you have an issue that needs fixing asap
B) you don’t use migrations and will never see the message as you never run makemigrations
I assume the objection to my solution is that there is a third situation, but I don’t think it was spelled out, or I missed it.
I’m tempted to set slow mode on this topic, but I’ll hold off for the moment.
I don’t see any real progress in the back and forth. There’s four folks here saying “OK, maybe a good idea as a system check” and then one saying “But not a system check” (which is unlikely to fly, and not something the others are going to be convinced about.)
I suggest we just leave it be, rather than keep spending time. (Progress is a ticket saying “There’s consensus to investigate a system check”, not arguing for a change in the way Django handles these things.)
(I’m going to mute the topic myself. Happy to lock it if anyone wants to flag it.)
2 Likes