jobflow should emit warning when no jobflow.yaml is found

[computron]

Describe the bug
If the user does not specify JOBFLOW_CONFIG_FILE as an environment variable, it's almost certainly due to a misconfiguration or because they forgot to set it / add it to their environment, not because they want to run with a MemoryStore.

Unfortunately, jobflow just happily runs (presumably using MemoryStore) and doesn't complain about the missing jobflow.yaml. This not only burns computer time with no output files written, but also results in user configuration because they don't know why things aren't being stored.

Suggested behavior:

• softer version - emit a warning when no JOBFLOW_CONFIG_FILE is set
• harder version - require a JOBFLOW_CONFIG_FILE and error / exit if not set, making it immediately apparent that the user should explicitly set a configuration file.

See also: materialsproject/atomate2#1423

[gpetretto]

Hi @computron, I think this is a good point. I wanted to add two comments given our use cases:

• I think it would be preferable to go with a warning, since it is often convenient to run simple examples without worrying of setting up the configuration. A hard error will make this difficult.
• This will probably raise a lot of misleading warnings for us in jobflow-remote, so if this warning is added it may be helpful to have some option to disable this programmatically, even if the JOBFLOW_CONFIG_FILE is not defined.

[computron]

This will probably raise a lot of misleading warnings for us in jobflow-remote
Can you clarify? I thought jobflow-remote would typically involve setting up a MongoStore.

My issue somewhat assumes that it is a rare event that someone would want to not set up a jobflow.yaml (e.g. hyper-quick debugging, in which case a warning is fine). If it is common for people to run, especially in production, without setting up jobflow.yaml then we can just leave things as they are.

It may be helpful to have some option to disable this programmatically, even if the JOBFLOW_CONFIG_FILE is not defined.

I would probably suggest a larger issue which is to standardize logging for jobflow (and downstream atomate2) more rigorously than what has been implemented so far. That way the solution is part of a broader logging capability rather than a one-off for this specific case.