This issue was prompted by and blocks #4563, but I'd want to fix it anyway.
Our settings() class is honestly pretty good considering the history, but the current design is still pretty dubious in places which deal with global state: specifically, we have both a global notion of "current profile", and can override that for a test function decorated with @settings(...). So:
settings() should give you "the current settings", inclusive of the effects of a decorator on the current test, if any.
- I think we can make this change immediately, without any deprecation period. We'll need to have settings know about
BuildContext, and in future maybe also 'the backend for this test case' to handle ObservabilityConfig, but that seems okay to do in the constructor.
settings.get_profile(settings.get_current_profile_name()) already works, if that's what you actually wanted.
- To avoid confusion, let's deprecate registering a new profile from inside an active test. I'd make it an error immediately to register a new profile while the current settings differs from the current settings profile, since that seems overly error-prone.
This issue was prompted by and blocks #4563, but I'd want to fix it anyway.
Our
settings()class is honestly pretty good considering the history, but the current design is still pretty dubious in places which deal with global state: specifically, we have both a global notion of "current profile", and can override that for a test function decorated with@settings(...). So:settings()should give you "the current settings", inclusive of the effects of a decorator on the current test, if any.BuildContext, and in future maybe also 'the backend for this test case' to handleObservabilityConfig, but that seems okay to do in the constructor.settings.get_profile(settings.get_current_profile_name())already works, if that's what you actually wanted.