Add support to bypass mache for using zppy on a new machine.

[chengzhuzhang]

When trying to test zppy on a not yet mache supported machine. I ran to an error:

Traceback (most recent call last):
  File "/usr/WS1/e3sm/apps/e3sm-unified/base/envs/e3sm_unified_1.10.0_login/bin/zppy", line 10, in <module>
    sys.exit(main())
  File "/usr/WS1/e3sm/apps/e3sm-unified/base/envs/e3sm_unified_1.10.0_login/lib/python3.10/site-packages/zppy/__main__.py", line 137, in main
    config["default"]["diagnostics_base_path"] = machine_info.config.get(
  File "/usr/WS1/e3sm/apps/e3sm-unified/base/envs/e3sm_unified_1.10.0_login/lib/python3.10/configparser.py", line 783, in get
    d = self._unify_values(section, vars)
  File "/usr/WS1/e3sm/apps/e3sm-unified/base/envs/e3sm_unified_1.10.0_login/lib/python3.10/configparser.py", line 1154, in _unify_values
    raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'diagnostics'

It doesn't seem that we can bypass this without changing mache. We don't test zppy on unsupported machines, but we can make zppy more portable by allowing users to manually set up base diagnostics path, web portal, etc.

[xylar]

I handle this in other tools by reading machine config files first from mache if they're available and then locally from the package if they're not. That approach would still require someone to add their machine to zppy but at least it wouldn't require modifying mache.

Here's an example from Polaris:
https://github.com/E3SM-Project/polaris/blob/39c06b7515828f5018749700ca73ed2ac5ed07db/polaris/setup.py#L560-L570

I added my old laptop morpheus as a "supported" machine this way:
https://github.com/E3SM-Project/polaris/blob/main/polaris/machines/morpheus.cfg

[xylar]

The obvious question might be, why do we have mache at all, then? The answer is that it's a pain to add a new supported machine to a bunch of packages this way.

[xylar]

A downside to this approach is that mache uses a standard Python config parser, whereas zppy does not and these machine files would therefore have a different format that other zppy config files (they need to match the mache approach for this approach to be attractive).

[chengzhuzhang]

The obvious question might be, why do we have mache at all, then? The answer is that it's a pain to add a new supported machine to a bunch of packages this way.

Great point. I slept on this last night. When we talking about porting zppy, it actually means porting the entire e3sm-unified mache system. There are so many floating elements behind the scene that need to be taken care of especially for external developers, it would be useful to have a brief porting guide for this system.

[xylar]

It's a pretty big job to fully support spack for E3SM-Unified on a new machine and I am spread extremely thin these days so I don't know when I could find time to write a porting guide. Adding a new machine without spack support should be as simple as creating a new config file in mache/machines, using the existing config files as templates. I think a porting guide for that is pretty overkill. But without spack support, a machine will be significantly less performant for certain tasks, of course.