Closed JamesHutchison closed 1 year ago
As an example for other library workarounds, there also needs to be a mechanism to allow future versions of the library to signal to the hot reloader that a workaround is no longer necessary. This could be an attribute on the library or a function the hot reloader could provide that could be called by library to signal that the workaround needs to be disabled.
On the same line of thought, custom workarounds need a way to register themselves. It would make sense to just add that when this is worked on.
The target audience for this project are individuals with large import times. A likely project would be a Django monolith.
Likewise, its for people who use pytest.
So it seems very likely that pytest-django will be used as well. I know one behavior to fix, at least in a prior version, is that it mutated the user's settings, and on reruns would further mutate them, so you'd get
test_mydatabase
thentest_test_mydatabase
, etc.