Incorrect docstring for apply_wildcard parameter in S3ListOperator

[simond]

What do you see as an issue?

The docstring for the S3ListOperator is incorrect for the apply_wildcard parameter:

:param apply_wildcard: whether to treat '*' as a wildcard or a plain symbol in the prefix.
        By default SSL certificates are verified.
        You can provide the following values:


        - ``False``: do not validate SSL certificates. SSL will still be used
                 (unless use_ssl is False), but SSL certificates will not be
                 verified.
        - ``path/to/cert/bundle.pem``: A filename of the CA cert bundle to uses.
                 You can specify this argument if you want to use a different
                 CA cert bundle than the one used by botocore.

Solving the problem

It looks as though most of the docstring should actually be part of the verify and not the apply_wildcard one. Moving the following lines up under the verify parameter should resolve:

        By default SSL certificates are verified.
        You can provide the following values:


        - ``False``: do not validate SSL certificates. SSL will still be used
                 (unless use_ssl is False), but SSL certificates will not be
                 verified.
        - ``path/to/cert/bundle.pem``: A filename of the CA cert bundle to uses.
                 You can specify this argument if you want to use a different
                 CA cert bundle than the one used by botocore.

Anything else

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[potiuk]

Feel free to open PR for it @simond . It seems that creating PR for one would take less time than describing it in an issue.

[simond]

I would normally agree but, last time I checked, setting up the development environment for Airflow to do a PR with tests etc was quite a lot of work.

[potiuk]

I would normally agree but, last time I checked, setting up the development environment for Airflow to do a PR with tests etc was quite a lot of work.

Well. It's ~ 15 minutes - mosty to pull images - to run Breeze (after installing Docker + Docker Compose + pipx basically) so I think it's not as difficult as you might think. And yes. Improvements to installing local environment (including using Hatch which manages Python installations and virtualenvs is coming sooon - See #36537 - so you might want to re-check it back when it's merged if you do not want to use Docker.

Maybe comment in the PR to get notified when it gets merged so that you can try it then ?

[simond]

I would normally agree but, last time I checked, setting up the development environment for Airflow to do a PR with tests etc was quite a lot of work.

Well. It's ~ 15 minutes - mosty to pull images - to run Breeze (after installing Docker + Docker Compose + pipx basically) so I think it's not as difficult as you might think. And yes. Improvements to installing local environment (including using Hatch which manages Python installations and virtualenvs is coming sooon - See #36537 - so you might want to re-check it back when it's merged if you do not want to use Docker.

Maybe comment in the PR to get notified when it gets merged so that you can try it then ?

I'll take another look as it sounds like it has changed since I looked last, thanks!

[josh-fell]

Closed via #36679.