Yes, to Black in principle. But (and this is a big but) no, not yet. Or not without testing how it affects our ability to cherry pick back to the release branch.
(My default would be to assume it makes them harder/almost impossible and this should be the almost last thing we do before we release 2.0) -ash On 27 June 2020 22:02:41 BST, Philippe Gagnon <philgagn...@gmail.com> wrote: >It's a good idea. > >It will make reading the codebase easier, and besides the whole Python >ecosystem is slowly moving towards adopting this code style. I >personally >have been a fan ever since the project launched. > >With regards to open PRs requiring a rebase, it's an annoyance for sure >but >if we do decide to standardize on any code style (which we should, >black or >not), we'll have to pull the bandaid eventually. > >Just my two cents. ;-) > >Philippe > >On Sat, Jun 27, 2020 at 4:13 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > >> Hi all, >> >> I would like to open the discussion to enable Black ( >> https://github.com/psf/black) - *The Uncompromising Code Formatter* >for >> automatic formatting of Airflow's entire codebase. >> >> I have created a WIP PR at >https://github.com/apache/airflow/pull/9550 >> >> Some of the caveats: >> >> - All the currently open PRs would have some kind of conflict >errors >> - It *might *make backporting harder (but should be ok'ish if we >enable >> black on v1-10-test but not 100%) >> - There are known issues with "line-lengths" not being honoured by >black >> (https://github.com/psf/black/issues/1161) and the workaround is >to use >> "#fmt: off". >> >> I would love to hear what the community thinks about it. >> >> Regards, >> Kaxil >>
