search

ansible / ansible-sdk

The Ansible SDK
Apache License 2.0
24 stars 14 forks source link

[WIP] options #26

Closed Akasurde closed 2 years ago

Akasurde commented 2 years ago
SUMMARY

Signed-off-by: Abhijeet Kasurde akasurde@redhat.com

ISSUE TYPE
COMPONENT NAME

ansible_sdk/executors/Subprocess/init.py ansible_sdk/executors/Subprocess/options.py ansible_sdk/executors/Subprocess/subprocess.py ansible_sdk/executors/init.py ansible_sdk/executors/common/init.py ansible_sdk/executors/common/desired_capabilities.py ansible_sdk/executors/mesh.py examples/example_subprocess_job.py

nitzmahone commented 2 years ago

So maybe we need to take a step back and talk about some design goals for a modern Python API. What you've got here more-or-less "works", but it's not a very user-friendly API.

Using a bunch of the modern Python features like (e.g.) type annotations, docstrings, and dataclasses, our APIs can be discoverable, self-documenting, support completion in Python IDEs, and get basic type and attribute validation all for free.

I'd suggest starting with implementing these options and executor-associated status objects as dataclasses with proper type annotations and docstrings. Ideally we'd make use of the new kw_only option from Python 3.10, but I don't know what's reasonable to require for a minimum Python version on the SDK, especially since both active versions of RHEL max out at 3.9...

Akasurde commented 2 years ago

superseded by #30