I propose to refactor functionality in common/ into a standalone module (something like bfrescox_tools ), which has no knowledge of a frescox installation. I think the symlinking could get verbose and messy as more files are added to common, especially if we want to break into submodules down the road (e.g. one for parsing for files, one for generating templates, etc.).
This also might make testing simpler, as the common/tools module would have its own set of unit tests, and the current packages would really only need to end-to-end tests.
Relatedly, currently there is much code duplication in the end-to-end tests (e.g. */tests/Test*Suite.py). It would be nice if there was a single class for reading test suites from json files, reading in benchmarks, and running the tests. Special cases could be handled by derived versions of this class (e.g. the base class could just read an NML file, run it, and compare fort16 results to a benchmark, while derived classes could generate the NML file from a template, or create the template and then generate the NML file from it, etc.). This class would live in bfrescox_tools, and be imported into both packages. The pro package would have to inject some functionality to also parse pro settings from the json test specs.
I propose to refactor functionality in common/ into a standalone module (something like
bfrescox_tools), which has no knowledge of a frescox installation. I think the symlinking could get verbose and messy as more files are added to common, especially if we want to break into submodules down the road (e.g. one for parsing for files, one for generating templates, etc.).This also might make testing simpler, as the common/tools module would have its own set of unit tests, and the current packages would really only need to end-to-end tests.
Relatedly, currently there is much code duplication in the end-to-end tests (e.g.
*/tests/Test*Suite.py). It would be nice if there was a single class for reading test suites from json files, reading in benchmarks, and running the tests. Special cases could be handled by derived versions of this class (e.g. the base class could just read an NML file, run it, and compare fort16 results to a benchmark, while derived classes could generate the NML file from a template, or create the template and then generate the NML file from it, etc.). This class would live inbfrescox_tools, and be imported into both packages. The pro package would have to inject some functionality to also parse pro settings from the json test specs.