`--strict` deprecation was botched - what to do about it

[bluetech]

In pytest 6.2, we deprecated the --strict option. In pytest 8, we purportedly removed it, however I completely botched the removal (1f8b39e), instead of removing --strict I removed its deprecation, effectively un-deprecating it.

I wonder if we should:

1. re-deprecate it and remove in pytest 10

2. remove it, on the idea that it did go through a deprecation period after all

3. go with our original plan which is to make --strict an "open" flag which enables all current and future --strict-* flags (currently --strict-markers and --strict-config). Since --strict currently means --strict-markers this will add --strict-config to --strict and document --strict as a proper feature.

4. other

I'd like to do 3 (and BTW also add ini options for strict and the current strict flags since I see them as project settings not per-run settings...).

(In #13757 I'm thinking it should be another strictness flag but not decided yet)

[Pierre-Sassoulas]

3. sounds like the best plan to me.

[RonnyPfannschmidt]

I like 3 with the option to use a list for it

That way we can eventually replace dozens of strict options with one thats a lists

[bluetech]

I like 3 with the option to use a list for it

Interesting idea but I see a couple of downsides:

• It makes it hard to set strict = true and then turn some specific strict_foo = false. The advantage of strict = true over an explicit list that it automatically enables new strict options when they are added. We can add syntax like strict = ["all", "-strict_foo"] but I think that's undesirable.

• We won't have a :confval: reference for each option.

Therefore I think separate options and a boolean strict, where the specific options override strict, is better.

The model I have is mypy which I think works pretty well. Users who want the "automatically updating strict" behavior use strict, those who don't set the specific options.

[bluetech]

BTW I forgot to mention xfail_strict, IIRC we want it in --strict as well since it's the recommended behavior (@RonnyPfannschmidt can you confirm?)

[RonnyPfannschmidt]

Yes