Make required fields both positional and optional in CLI

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.

[bugraoz93]

closes: #60142

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Sonet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

There is a small problem with headless mode, will check later

[shivaam]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

[bugraoz93]

I was just thinking about this. Supporting both positional and flag styles for the same param isn't something most CLI libraries or popular tools do. We're adding maintenance burden, constraining future changes as all CLI libraries might not suppor this feature, and expanding the testing surface forever. Since airflowctl is still pre-1.0, feels like this is the natural window for a clean break rather than committing to maintaining a non-standard approach indefinitely.

Since the layer we are adding is light, either way works. Just wanted to share my thoughts.

PS: Sorry for cross posting my message here, since I closed my PR as we have this one open. My PR: #64812

No need to sorry at all, we are discussing and that is how the best things come out :)
Agree, as I mention in your PR as well, that would be the cleanest approach and I also would like to go with it my heart while providing both feature we can ask users and dropping cleaning can also happen incrementally while 1.0 discussions are in. While on the side I was considering even if we are pre 1.0, this would still impact the current user base and cause another migration effort.
Let me create a discussion for this. Let's hear from community first. I am also happy to go with clean approach if discussion goes well. Will share the discussion link soon here as well, please join there too :) Until then conveting this to draft

[bugraoz93]

https://lists.apache.org/thread/td0s78l01031dgn5hh5gjybx55yoj7t2

[bugraoz93]

https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm
Lazy consensus reached.