Ruff enable fbt

[bandophahita]

The final ruff rule.

FBT triggered on the fact that actions like Enter should not use bool in a positional argument. Unfortunately changing the constructor for these actions could cause folks some issues. This PR attempts to give users some time to adjust before we update these constructors.

[perrygoy]

I had one concern, and a couple small suggestions. I think this is a good approach though!

[perrygoy]

I don't think you're actually testing anything here, i think you need to add a as caught_warnings to the context manager and then do some assertions on it later. See the docs here: https://docs.python.org/3/library/warnings.html#testing-warnings

[perrygoy]

This same comment applies to the other tests below.

[bandophahita]

This test works, albeit it's proving a negative. It's testing to ensure the warning does NOT occur when mask keyword is used.

It wasn't obvious to me either, but using with warnings.catch_warnings() along with warnings.simplefilter("error") causes all warnings to raise an exception when they occur.

You can try it out by removing the keyword.

# THIS passes (as expected)
        with warnings.catch_warnings():
            warnings.simplefilter("error")
            Enter("", mask=True)

# but THIS will fail 
        with warnings.catch_warnings():
            warnings.simplefilter("error")
            Enter("", True)

[perrygoy]

OK, i see now that we get an error for the raised warning, but i don't like that the error is the warning, you know? I'd prefer an assertion that makes it clear what the problem was. Is that possible to do with what they've got in the docs?

I guess it'll only be relevant for a couple months, so i think i can be OK with this.

[bandophahita]

I updated the tests. They explicitly state when a warning was raised unexpectedly, rather than only raising the warning.

[perrygoy]

Very nice approach! Let's get this in and do a little release soon to get the deprecation out.

[perrygoy]

OK, i see now that we get an error for the raised warning, but i don't like that the error is the warning, you know? I'd prefer an assertion that makes it clear what the problem was. Is that possible to do with what they've got in the docs?

I guess it'll only be relevant for a couple months, so i think i can be OK with this.

[perrygoy]

Actually we probably want to add a page to the docs about deprecations, like this one in ScreenPy: https://screenpy-docs.readthedocs.io/en/latest/deprecations.html

[perrygoy]

Thanks for all the updates! I appreciate the added effort to deprecate before removal. I'm sure there's someone out there who is using these Actions this way.