You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have only recently discovered airflowctl, and I fell in love with it immediately.
I would like to integrate it into our runbooks, i.e. Jupyter notebooks.
I think the CLI is well designed.
However, it would be even nicer to be able to directly import the functionality into Python, and extend it there.
I propose to more strictly separate the CLI logic from the underlying business logic related to the Airflow REST API, and expose the latter as a Python API, i.e. an importable collection of modules and functions.
Other than the advantages, I do not see any advantages since this is possible without any breaking changes.
We would follow the CLI relatively closely.
If the maintainers are open to the suggestion, I would be happy to take it into my own hands.
I would be happy to provide an outline of what the function signatures would possibly look like.
Afterwards, I would implement it, and refactor the existing commands/ modules.
Since the existing commands are only refactored, it is possible to break it into a number of smaller PRs.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I have only recently discovered
airflowctl, and I fell in love with it immediately.I would like to integrate it into our runbooks, i.e. Jupyter notebooks.
I think the CLI is well designed.
However, it would be even nicer to be able to directly import the functionality into Python, and extend it there.
I propose to more strictly separate the CLI logic from the underlying business logic related to the Airflow REST API, and expose the latter as a Python API, i.e. an importable collection of modules and functions.
Other than the advantages, I do not see any advantages since this is possible without any breaking changes.
We would follow the CLI relatively closely.
If the maintainers are open to the suggestion, I would be happy to take it into my own hands.
I would be happy to provide an outline of what the function signatures would possibly look like.
Afterwards, I would implement it, and refactor the existing
commands/modules.Since the existing commands are only refactored, it is possible to break it into a number of smaller PRs.
What do you think?
All reactions