HackMD
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:
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.
