I find it odd that it both warns and then errors (the error means it doesn't change, and thus the warning is incorrect)

Consider moving the check up the call stack one level to set_layout_engine such that only one of the error or warning occur.

I think this is over-reach here. People are allowed to change layout engines.

The problem is if people have set the layout engine and then specifically call plt.tight_layout, usually because they are copying and pasting magic commands, and then wonder why constrained layout got clobbered. This check should be in the tight_layout method, not every time the user uses the API to switch the engine.

I'm not sure what @ksunden was referring to wrt to an error - it is very possible to call tight_layout without an error, so maybe the test was malformed.

That makes sense, thank you.

Regarding the error, there was a possibility of a new UserWarning immediately followed by a RuntimeError from figure.set_layout_engine.

I was referring to a specific test that was included which had both a warning and an error with pytest checks for both. However in the event an error gets raised, the warning is pointless as that means the layout does not get changed.

I agree that I'm not sure it should warn quite so eagerly, but honestly not convinced it should warn for tight_layout either... that seems like a pretty explicit "I want a tight layout" call, so not sure why we are looking to warn that it is doing exactly what is asked.

It feels like that is just as likely to warn users who expect it than it does to catch users who don't expect that behavior.

but honestly not convinced it should warn for tight_layout either... that seems like a pretty explicit "I want a tight layout" call, so not sure why we are looking to warn that it is doing exactly what is asked.

If someone at the top of the code says plt.figure(layout='constrained') and then at the bottom of the code says plt.tight_layout() I think it is likely they have made a mistake.