No this is not right, as running tests locally would behave differently than through GH action, would fix this later

I realized the original method might be the best I could do so far. If we were to export the env var from the test workflow config file python-package.yml, it would only be effective running on actions (not locally).

However I believe having that MPLBACKEND set is still beneficial:

• The Windows backend tk for Github runner is pretty flaky at least for pymatgen, matplotlib test use non-interactive agg backend  materialsproject/pymatgen#4168
• I believe it's recommended to use Agg for non-interactive purpose anyway

pytest doesn't seem to natively support setting environment variable from pyproject.toml and there is a plugin pytest-env just for this purpose (though with the price of added an additional tests dependency):

[tool.pytest_env]
HOME = "~/tmp"
RUN_ENV = 1

Hi @DanielYang59 , before we merge, can you please provide a bit more context on why this change is needed and what are the issues when we don't have this?

I am not that familiar with lot of what matplotlib has to offer. So just want to understand bit better 😄

And thanks in anycase for this PR

can you please provide a bit more context on why this change is needed and what are the issues when we don't have this?

Absolutely, I owe you an explanation here:

• agg is the recommended non-interactive backend in the first place, so in a non-interactive scenario (unit test/batch image generation script), it should be used
• The reason for specifying a backend for lobsterpy is lobsterpy check the image size in test, but the image size has different rounding behaviour on MacOS (macosx backend), leading to test failure
• More practical reason is the installation of tk (default windows backend) seem to fail intermittently for GitHub Windows runners (at least for pymatgen), and would result in intermittent test failure

Thanks @DanielYang59

No problem thanks for reviewing