In my comment in #26031 I was imagining something like

_timeeut = os.envrion.get('MPLTESTTIMEOUT', 20)

and then setting MPLTESTTIMEOUT in all of the CI setups, however if CI is always defined this is way simpler!

Please update the PR title/commit message to be more descriptive; we won't know what Issue #26031 means looking through git logs.

Seems to pass all the CI tests, so I guess the slow ones where this matters at least define it.

or we got lucky on these runs.

Yes, indeed it could be lucky. CI is set on most of the runners it looks like (maybe not Azure Pipelines?):
https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables
https://github.com/orgs/community/discussions/26628#discussioncomment-3252605

But, perhaps we don't only care about CI systems, but also downstream packagers... Which would mean the MPL-specific environment variable may be the better way to go.

Tracing through blame, we have gone from 1s up to 120s now! Increased from both downstream packagers and our CI systems, so both use-cases seem relevant.
65426e7
602e9f9

would changing the code to this: _test_timeout = int(os.environ.get('MPLTESTTIMEOUT', 120)) be sufficient?

It seem axiomatic that timeouts are always "wrong" no matter what value you pick :-p

would changing the code to this: _test_timeout = int(os.environ.get('MPLTESTTIMEOUT', 120)) be sufficient?

partially. We would also need to set that env in all of our CI configs and if downstream packagers are relying on this we need to document the change for them so they can set the ENV in their build systems.

I'm going to close this as a slightly more broad solution was merged in #26235

Thank you for looking in to this, sorry this one didn't end up getting merged, hope to hear from you again!