Currently, many of the conf and op mode commands are installed in libexec and referenced in the xml / vyatta code. As I understand, the reason for this location is to follow the Debian installation guideline and the Linux Standard Base.
However, all these programs could be moved within the python repository (for example, in some entry/conf and entry/operation folder) and python entry points used to call the code. This explain very well entry points: https://amir.rachum.com/blog/2017/07/28/python-entry-points/
Then the program could be organised through a central command tool / entry point, the same way git has many sub-program controlled from the central "git" utility.
A first layer parses the options and then call the next right entry point.
It should be possible to have a `show`, program which does dispatch for all the show commandsto the right python file such as `show dhcp` to `./src/op_mode/show_dhcp.py` (wherever it is moved). The mapping between the XML and program could then be made one-to-one, allowing to not have to be explicity set where the command to hande a "tag" is, but rely on the xml structure itself.
At this point, it should be possible to use pex (https://www.youtube.com/watch?v=NmpnGhRwsu0) or python3 built-in zipapp to replace the entry points on the OS with single. file python program executable.
It would then allow easy "hotfixing" for customers. Debian `update-alternatives` could then be used to change which program is run, while keeping the previous version, and some soft update could then be performed on the running server without requiring a reboot and allowing a rollback.
The same mechanism could also be used when coding to test new code while not affecting the installed system, reducing the risk for our testers should a rolling version have an issue.
If the ultimate goal is to remove the old vyatta code, then organising the code in a way which matches the command should be a step in the right direction.