I think a good starting point is outputting some json to sys.stdout., logging warnings/errors with logging.StreamHandler (defaults to sys.stderr, fd 2, for all log methods, at all log levels), and setting rc=0 if there are none.
Working with file-like output also implies some different scenarios for handling file descriptors (Linux) and whatever (Windows):
main.py passes file descriptors to the plugin's describe method, and the plugin does the printing
Each plugin would potentially output differently, but each plugin will have a different definition of what properties describe an 'app'.
gives plugin the opportunity to log to something like Cloudwatch or S3
main.py receives a class instance from the plugin
plugins would need to implement or subclass from the quickhost package, which does not exist.
Simpler plugins (I like)
Standardized output format
After talking it over with myself, I think this guy has some really good ideas, regarding 2). Either way, I'm not just throwing it in a dict as the api's end result.
Description
Plugin functions whose return values are handled by
main.py
'scli_main()
function need to return appropriate values forstderr
,stdout and rc
.apt
output to a file:create
wait_for_hosts
is animateddestroy
wait_for_hosts
is animatedupdate
describe
I think a good starting point is outputting some json to
sys.stdout.
, logging warnings/errors withlogging.StreamHandler
(defaults to sys.stderr, fd 2, for all log methods, at all log levels), and settingrc=0
if there are none.Working with file-like output also implies some different scenarios for handling file descriptors (Linux) and whatever (Windows):
main.py
passes file descriptors to the plugin'sdescribe
method, and the plugin does the printingCloudwatch
orS3
main.py
receives a class instance from the pluginquickhost
package, which does not exist.After talking it over with myself, I think this guy has some really good ideas, regarding 2). Either way, I'm not just throwing it in a dict as the api's end result.