> How do you make it changeable any time? User needs to be able to specify what coordinator to use in the config, and you can’t break that later. We have only *jdk* coordinator now . So I will revert the question. How are you going to configure two "jdk" `coordinators` when you have separate distributions running "java"? Are you planning to install two "coordinator-jdk" packages? This isn't possible in Python unless you build almost the same package with jdk-11, jdk-19 built in? My understanding is that you will have configuration options to choose between "jdk-11" and "jdk-19." This "jdk" package of yours will simply have a list of "jdks" linking to the Java interpreters.
So, it doesn't matter if it's a single "coordinator-jdk" package or everything in "airflow.sdk._coordinator."jdk" package or "airflow.sdk._bridge.jdk" package in the task-sdk. Regardless, you cannot install two "jdk" packages, whether they are separate distributions or if the package is in "task-sdk" and you have to configure which of the "jdk" bridges you want to use. Yes. Sometime later, when we also have Go/TypeScript or other languages, we might decide to centralize some APIs, create a "true" coordinator package and separate distributions. And splitting into different packages will be absolutely no problem then. Nothing will stop us from doing it. It will save a lot of time for all the "distribution" issue - including releases, packagig, CI and everything connected - and it does not absolutely block us from further split later. J. On Wed, May 13, 2026 at 3:47 PM Tzu-ping Chung via dev < [email protected]> wrote: > > > > On 13 May 2026, at 20:42, Jarek Potiuk <[email protected]> wrote: > > > > Not really. I proposed an internal package that can be changed **any > time**. Users aren't supposed to use those items. We can clearly mark them > with "_" and also describe them thoroughly in the public API documentation. > And no. Initilaly providers were **not** in arflow at all - you started > from step 2. Step 1 is that they were added at some point in time long > before my time. Hooks and operators as "API" were creaed quite early in the > concept of Airflow - and the first implementations were added then. Then, > after common patterns emerged, those hooks and operators were grouped into > providers (they were not initially) and only moved out after quite some > time. As I see it - you even admit yourself that things will look > differently for different languages, and maybe even we will not need > bridges for some of them at all. So why should we introduce new concept if > we know currrently that it applies only to "JDK"? I fail to see why we > should proceed if we already know the patterns are unlikely to be reusable > in their current form. > > How do you make it changeable any time? User needs to be able to specify > what coordinator to use in the config, and you can’t break that later. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
