Better ways to pass in unary functions and lattice stabilities

[bocklund]

Somewhat related to #123 and the repository https://github.com/PhasesResearchLab/ESPEI-unary-refstate-skeleton/

As of ESPEI 0.7.9, custom unary reference states can be added by a skeleton repository and using setup.py entrypoints. In practice, doing this is not very ergonomic for users and does not address simple use cases like overriding a particular unary or lattice stability (while accepting the SGTE Unary 5 expression otherwise).

This discussion topic should track ideas for alternatives to the current system.

The nice aspect of the current approach is that anyone can create and distribute a reference state without changing ESPEI code. Any solutions should support this use case.

Some key issues with the current method are:

• Setuptools entrypoints may be difficult for users to configure. I'm pretty sure that changes to the name of the reference state or the module that the reference state is stored in would mean that users would have to repeatedly pip install their own package to set up the entry points again.
• The current ordered dictionary approach is somewhat unclear and not self-documenting
• Most users think about and store their unary/lattice stability equations in TDB files. If the expressions are piecewise in temperature, it's not trivial to "copy-paste" the expression to a valid SymPy Piecewise expression, which could lead to translation errors.
• Users need to have all the unary and lattice stability data for their system in unary package. There's no concept of overriding just one piece of data. This means that small modifications in user-contributed unary reference state packages would require duplicating everything, which is problematic for receiving updates to the unary expressions in the future.

[bocklund]

One solution is to make the reference energy and lattice stabilities proper objects. If the reference data were a class, users would be free to subclass and inherit the existing unary and lattice stability functions to make minor changes/additions without duplication.

Using a mechanism like the __init_subclass__ magic from PEP 487 could enable ESPEI to build a registry of unary reference state classes as long as the class was created before ESPEI is run. It's not immediately clear how one could do this on the command line, but it's very easy to imagine importing a package that includes one or more reference states if ESPEI is run from a Python kernel (e.g. a Jupyter Notebook).

Some further development is required to decide what the interface ESPEI should expect this class to conform to, but a class would make it very easy for users to provide the Gibbs energy functions any way they like. They could even distribute a TDB file and create the unary functions dynamically from the TDB (this could even be a built-in supported feature).