Standard provider bash operator

[gopidesupavan]

Moving bash operators/sensors to standard provider

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[gopidesupavan]

moving this bash operator to standard provider, has module path changes in systems test, integration tests.

failures in python client tests, i am thinking due to bashoperator path change, causing dag not loaded.
Checking remaining tests.

[jscheffl]

For this change - if we basically add all example DAGs into the exclude list - the check has almost no effect.

Can you re-work the check such that no provider except standard provider dependencies are accepted?

[gopidesupavan]

Yes, agree. will check.

[jscheffl]

This all looks a bit strange now in my eyes. All example DAGs sitting in the core are requiring a provider package. Smells like a cyclomatic package dependency.

1. Should we move the example DAGs into the provider as well? (Then they are hard to find :-( )
2. Should we load the core operators from the compatability alias? (Then we have bad examples)
3. Any other ideas?

[jscheffl]

Note: This was an open question to the community :-D

[jedcunningham]

1. Seems reasonable to me. Not that hard to find. But load_examples probably needs more work then. Probably not be worth it.
2. No.
3. Leave it? Airflow 3 will require the standard provider anyways right?

Side note: We don't need the try/except fallback imo.

[ashb]

What do we do for the other bundled providers - http, sqlite (plus two others - ftp and email)?

[jedcunningham]

My 2c, I'm really not sure we need the time/core part of this. Seems better to just have

airflow.providers.standard.operators.weekday
airflow.providers.standard.operators.bash

[gopidesupavan]

i am ok with suggestion. :)

[gopidesupavan]

Could you please help on this, kubernetes executor tests are failing with dag not found example_kubernetes_executor and example_bash_operator. one option i tried copying the standard package to k8s build container, but its still failing with same reason.

[gopidesupavan]

Additional prod image tests also failing, as it doesnt have the standard provider. inside latest prod image pull.

[gopidesupavan]

Additional prod image tests also failing, as it doesnt have the standard provider. inside latest prod image pull.

Any suggestions for these tests?

[gopidesupavan]

After reviewing the logs, it seems the reason the k8s tests are failing is due to the absence of the standard provider package in the image. This is because i guess the standard provider not included in the prod_image_installed_providers.txt file ?

Is it okay to add standard provider in to that file?

[jscheffl]

After reviewing the logs, it seems the reason the k8s tests are failing is due to the absence of the standard provider package in the image. This is because i guess the standard provider not included in the prod_image_installed_providers.txt file ?

Is it okay to add standard provider in to that file?

Yes. At least from the community discussion we always expected that the new "standard" provider will be a standard install and dependency. So adding to prod image would be the natural consequence. Hope that fixes the problems you had (and sorry for responding late,,,)

[gopidesupavan]

After reviewing the logs, it seems the reason the k8s tests are failing is due to the absence of the standard provider package in the image. This is because i guess the standard provider not included in the prod_image_installed_providers.txt file ?
Is it okay to add standard provider in to that file?

Yes. At least from the community discussion we always expected that the new "standard" provider will be a standard install and dependency. So adding to prod image would be the natural consequence. Hope that fixes the problems you had (and sorry for responding late,,,)

Thank you :) , I am glad the debug helped me to understand how the ci workflow setups and working process.