bugraoz93 commented on PR #45300:
URL: https://github.com/apache/airflow/pull/45300#issuecomment-2726847175
Many thanks for your swift response! We all press enter around the same for
sending the comment :D
>Yeaah. Once I finish the apache-airflow-core we can add apache-airflow-cli
and figure out how to avoid or mitigate duplication.
Cool, great to know!
>My first thought (also got a quick chat with @jedcunningham ) is that some
duplication is OK as long as we have a pre-commit that will take care to
synchronize the client side in apache-airflow-cli with the command and "server"
side in the API/scheduler we should be good. Does it sound good?
Sounds good! It seems inevitable to have duplicates at the first steps.
>BTW. I just reserved apache-airflow-cli and apache-airflow-ctl in PyPI for
that separate distribution.
Amazing news! :partying_face:
>I think this is a good plan, especially if we commit to moving the client
etc out before Thursday :)
Sure, I can move out remote and client part until Thursday :)
>As long as we are able to prove out that the interaction with the api, and
foundational pieces that are in core, are good by feature freeze, we are
golden. This new cli package wouldn't fall under the freeze :)
Make sense! I think in this way, we will definitely sure the core part
working without any client integration. We just need to figure out when to run
with which command or parameter to state it is remote or local without
separating the package :)
>Agreed. I also like your idea @jedcunningham of keeping current commands
without auth and a separate package for remote stuff. We can re-use airflowctl
name too since I own that. Naming aside, I like the idea
Great, I would be happy if we use `airflowctl` :D Thanks Kaxil!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
