Hello here, I've been iterating on Py 3.13 support and have it "almost" green.
https://github.com/apache/airflow/pull/46891 Currently (until connexion 2.15.0 release) - we cannot make it work with FAB so FAB (Among others) is excluded. However this brings the need to fix one more incompatibility (except that we need to wait for at least RC release of the next provider's wave) - serve_logs implicitly depends on Flask/Fab. Currently our "serve logs" method to serve logs for celery workers is still part of the "airflow-core" and indirectly depends on Flask/FAB APP being installed. There was a discussion that it should be possible to easily rewrite it using fast-api, and it's the time we actually need it to: * have Python 3.13 support * become truly FAB-independent I created an issue for it https://github.com/apache/airflow/issues/52526 - and since I have not been involved in fast-api development, I guess it will be faster by someone who was. Can someone help with it ? J. On Mon, Jun 23, 2025 at 8:00 AM Jarek Potiuk <ja...@potiuk.com> wrote: > I also started to do more preparation and extracting things that we will > need to merge first and release providers with some limits lifted. We need > to make our providers released in PyPI prepared upfront because currently > we are not able to generate PyPI constraints for Python 3.13 - I already > have one of those merged - https://github.com/apache/airflow/pull/51994 > where we have to exclude `ray` from Python 3.13 and release provider before > we get the PR "green" - similarly I have just created > https://github.com/apache/airflow/pull/52060 to all providers that are > currently limiting pandas (unnecessary it seems from my tests in 3.13 PR). > > J. > > > On Mon, Jun 23, 2025 at 7:46 AM Amogh Desai <amoghdesai....@gmail.com> > wrote: > >> Thanks for taking this on Jarek. >> >> These are not easy tasks to work on and I cannot think of a better person >> to do it than you! >> >> I will review it shortly this week. >> >> I think it is a good thing to introduce in Airflow 3.1 and I would not be >> too much in favour >> to cherry pick it to the 3.x series, just for convenience sake. >> >> Thanks & Regards, >> Amogh Desai >> >> >> On Fri, Jun 20, 2025 at 2:47 PM Jarek Potiuk <ja...@potiuk.com> wrote: >> >> > Hey here, >> > >> > Over the last few days and weeks I made significant progress with Python >> > 3.13 support and while the PR is not yet fully green - we are getting >> > close. I undrafted my PR recently: >> > >> > https://github.com/apache/airflow/pull/46891 >> > >> > I have a kind request for others to start reviewing it, I will be happy >> to >> > respond to questions and I am also happy to accept some fixups to solve >> > things in a better way if possible, I did a few hacks and left some >> TODOs >> > that might need some creative ideas to be solved in a better, simpler >> way. >> > >> > I split the PR into several commits - and keep it continuously rebased >> on >> > top of the latest main. I had to remove some providers (including FAB - >> > which is actually cool, because we can finally see that airflow >> codebase is >> > finally working even without FAB being around) - some of them are yet to >> > implement Python 3.13 (for example Apache Beam is working on it) so we >> > might add them back soon. >> > >> > Note - Python 3.13 was a WAY more difficult migration than Python 3.12 - >> > there were a number of things removed/changed and small behavioral >> changes >> > that we relied on, also the dependencies are catching up way later, and >> > there are some tricky dependencies of ours that make things more complex >> > when it comes to selecting "min" versions of those. But we are finally >> > getting there. >> > >> > Looks like we will be on-time to have 3.13 support for Airflow 3.1. We >> > might also attempt to cherry-pick it for 3.0, but it might be too much >> of a >> > hassle, so we can decide after we merge this one to main. >> > >> > J. >> > >> >
