Supplychainpy is a Python library for supply chain analysis, modelling and simulation. The library assists a workflow that is reliant on Excel and VBA.
Currently, the core logic and the reporting suite are in the same library, separating the two components of the project will:
Help maintain the orthogonality of the codebase and keep the code decoupled. Fixing bugs, making enhancements in either the core logic or the reporting suite should not have side effects.
Make it easier to work on the project in smaller sprints.
Make it easier to document.
Allow dependencies to be precise.
Remove the requirement for a full release of the library when bugs get announced in dependencies for the frontend (some javascript libraries).
Make it easier to contribute to the frontend by reducing the need for domain knowledge. I spoke with a UX/UI company about the reporting suites and summarised the responses in this blog post.
Improve the test coverage and completeness. The current test suite does have unit tests but not functional tests (there are a few basic ones).
Help keep the codebase Pythonic and reduce technical debt and "code smells".
These are some of the main points I think make separating the project a sensible decision. If there is anything else to consider, please comment.
Currently, the core logic and the reporting suite are in the same library, separating the two components of the project will:
Help maintain the orthogonality of the codebase and keep the code decoupled. Fixing bugs, making enhancements in either the core logic or the reporting suite should not have side effects.
Make it easier to work on the project in smaller sprints.
Make it easier to document.
Allow dependencies to be precise.
Remove the requirement for a full release of the library when bugs get announced in dependencies for the frontend (some javascript libraries).
Make it easier to contribute to the frontend by reducing the need for domain knowledge. I spoke with a UX/UI company about the reporting suites and summarised the responses in this blog post.
Improve the test coverage and completeness. The current test suite does have unit tests but not functional tests (there are a few basic ones).
Help keep the codebase Pythonic and reduce technical debt and "code smells".
These are some of the main points I think make separating the project a sensible decision. If there is anything else to consider, please comment.