--- tags: work --- # Knowledge Sharing For the upcoming knowledge sharing meeting with Jesus and his team, he brought the following questions that should be answered and discussed. ### How to achieve a good internal consistent structure of commands Choose a CLI argument parsing framework that everyone can agree on. I personally like `click` but there are several others out there too. Others to consider: - https://docs.builtoncement.com - https://github.com/tiangolo/typer Going beyond that, it's also important to agree on the application structure. Don't be afraid to use the same amount of rigour as you would use in designing a web application backend. I find it helpful to think in terms of services/apps much like how Django applications are designed. For example, if there this CLI is going to be interacting with an HTTP API, the Python code for interacting with this API should be kept in a separate module and define a public API for the rest of the CLI application to use. That way, if you need it elsewhere in the future, it can be refactored out to stand on it's own as its own library. I also think it's important to keep display logic as separate as possible too. For every command you write, assume you will always want various types of output. The could be JSON, YAML, TXT. The main idea is that you would not have to do significant refactoring just to add a new supported output format. ### How to document the commands, so that a user can easily know how to use the tool Use Sphinx to generate internal docs. Use autodoc tools that work with Click and Sphinx. ### How to plan for the expansion of the cli tool in lockstep with new features of AS Make it as modular as possible. Maybe it's also not to soon to think about how third parties may add extra functionality if necessary. Feature flag where sensible. ### How to support different versions of python Use github action testing matrices ### Building packages for the cli (also with different python versions in mind) Could easily create a conda package for it. Not sure how it's going to be hosted though (private conda repo?) ### Testing infrastructure for the cli (is there a nice way to have E2E tests for the cli) Just split up the tests in your repository along "integration" and "unit". You'll be able to run these in CI.