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 if it gains python3 support (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.

(later edit)

How this can be implemented in practice was tested with https://github.com/thomas-mangin/vyos-extra

• the program can be installed using pip/setuptools and the "vyosextra.main:main" entry point, generating a "vyos" program.
• the "release" program in the root folder generates a self-contained executable (using the builtin python3 zipapp library) which can be place before in the path, taking precedence over the installed version.
• each feature "vyos ssh", "vyos update" is a single program and could be installed independently using other entry points
• dropping a program in the folder automatically registers it to the main "vyos" program, each program has a "def main()" with a docstring used for the "-h"
• the assets in the data folder are converted into python dict and used when the program is a zipapp.

A similar design is considered with vyos where:

• all the validator could be presented as one application
• all the ops command could be presented the same way, matching the autocomplete syntax
• the conf command could be made to match the xml hierarchy removing the need to have the name be explicitly configured in the xml
• it may be possible to add a new feature which validates of part of configuration without committing it