Opened 5 years ago

Closed 5 years ago

#33140 closed New feature (wontfix)

Enforce ordering of checks.

Reported by: David Szotten Owned by: nobody
Component: Core (Other) Version: 3.2
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

​https://github.com/django/django/pull/8967 changes the checks registry to use sets instead of lists. i may be missing it, but i can't see a ticket reference or any reason for the change

i just had a bug where the behaviour of a generated file (happened to be by ​https://github.com/adenh93/django-typomatic) depends on collecting classes, which in turn depends on the import order of files in my project

i had two different invocations get different orderings of checks causing different import orders

could we consider switching back to lists? or e.g. using sorted instead of list in get_checks ​https://github.com/django/django/blob/8036b53de61f16098a2f22c50621987182bdfaed/django/core/checks/registry.py#L96

Change History (3)

comment:1 by Carlton Gibson, 5 years ago

Component: Uncategorized → Core (Other)
Resolution: → wontfix
Status: new → closed
Summary: order of checks → Enforce ordering of checks.
Type: Uncategorized → New feature

Hi David.

I don't think it's really part of the System Check API/contract that they're run in any order. I don't think making it such is a good idea. (Indeed it might be a feature that they're not...) We could throw in the sorted — what would it hurt? — but then folks would end up using/depending on it. As such I'm inclined to wontfix.

The change from the PR was so long ago now I can't see a realistic case for arguing there's a regression here. A set was the right collection type all along.

So to your problem, I think a change in django-typomatic is the way to go. Even if we accepted this here it would be roughly a year before it was isn an available version of Django. Applying some kind of sort in django-typomatic, on the other hand, could be available ≈immediately, and it's probably something it should do anyway…

comment:2 by David Szotten, 5 years ago

Resolution: wontfix
Status: closed → new

to be clear, i wasn't suggesting guaranteeing any _particular order, but rather making sure the order is consistent between invocations and systems

django-typomatic was my example (and i fixed my issue by disabling the checks for the management command in question), but the general problem is hard-to-track-down bugs caused by different import orders on different systems (in my case i have yet to figure out what even _caused the iteration order to change)

(happy for you to re-close if you still think that's the best action here, but wanted to clarify my suggestion)

comment:3 by Carlton Gibson, 5 years ago

Resolution: → wontfix
Status: new → closed

Hey David. I'll reclose since it's best to take these kind of discussions to the DevelopersMailingList (as per the ​triage guidelines for wontfix tickets)

My thought was that really System Checks should be able to run in any order — like --random for a test runner — that was my point about Indeed it might be a feature.... Maybe that's not right though, so seeing what a wider audience think may be worthwhile.

...bugs caused by different import orders ...

I don't know but, my thought here is that ordering the system checks is at best a band-aid over a deeper problem here. Import order isn't really something that's under user-control. Relying on it seems to be asking for trouble... — but maybe others can speak differently.

Note: See TracTickets for help on using tickets.
Back to Top