We currently have all logic for managing contracts in zos-cli, including convenient js wrappers around Kernel and AppManager.
These classes are useful for writing deployment scripts (see complex-example), which involve setting up the app manager, creating proxies, etc. They are also helpful in testing.
It would be useful to move these libraries that wrap the contracts and provide simple access to their methods to either zos-lib or a separate zos-lib-js project, so they can be used from any project without requiring usage of the CLI.
As for the CLI itself, several commands would be more useful when invoked from a script rather than via command line, for example, when creating proxies that require some complex initialization, or when deploying all the contracts listed in a package.zos.json. Using a middle layer as suggested by @ajsantander here could be a good option, if invoking the CLI commands by importing them is too cumbersome.
This could imply:
Adding new classes to manage the package.zos files, instead of having just read-write utils, providing methods for listing contracts, adding new ones, recording operations, etc.
Adding classes that compose the package.zos manager and the AppManager wrappers provided by the zos-lib (described in the first paragraph here). These classes would expose simple methods that delegate operations to the package.zos managers and the contract managers.
Move most logic from the commands in the scripts folder to these classes.
A user writing a script could then rely on these middle-ground classes, or use the ones provided by the zos-lib directly if they don't want to use tha package.zos files structure.
We currently have all logic for managing contracts in zos-cli, including convenient js wrappers around Kernel and AppManager.
These classes are useful for writing deployment scripts (see complex-example), which involve setting up the app manager, creating proxies, etc. They are also helpful in testing.
It would be useful to move these libraries that wrap the contracts and provide simple access to their methods to either zos-lib or a separate zos-lib-js project, so they can be used from any project without requiring usage of the CLI.
As for the CLI itself, several commands would be more useful when invoked from a script rather than via command line, for example, when creating proxies that require some complex initialization, or when deploying all the contracts listed in a package.zos.json. Using a middle layer as suggested by @ajsantander here could be a good option, if invoking the CLI commands by importing them is too cumbersome.
This could imply:
A user writing a script could then rely on these middle-ground classes, or use the ones provided by the zos-lib directly if they don't want to use tha package.zos files structure.