I had some ideas about the CLI I wanted to share, specifically around variants of ADOP and how to keep it flexible enough to support them and allow contribution.
I think that the CLI itself, and anything that is agnostic of how/where ADOP is deployed such as the project/workspace/cartridge commands, needs lifting out into its own repository that becomes the new entry point
Each CLI "type", such as "compose", should then come from repositories such as this containing not only the CLI commands required for it but all of the supporting assests
CLI types would be linked into the main repository via sub-modules and only cloned when someone uses that specific command
The idea is that if someone decided to do a Kubernetes implementation, for example, that they'd be able to extend the CLI to support it without having to interfere with this repository. The CLI would act as the common umbrella that encompasses all variants of ADOP and remain independent of the chosen implementation.
I had some ideas about the CLI I wanted to share, specifically around variants of ADOP and how to keep it flexible enough to support them and allow contribution.
The idea is that if someone decided to do a Kubernetes implementation, for example, that they'd be able to extend the CLI to support it without having to interfere with this repository. The CLI would act as the common umbrella that encompasses all variants of ADOP and remain independent of the chosen implementation.