Makes sense, +1 On Wed, Jul 22, 2026 at 5:21 PM Brent Bovenzi via dev < [email protected]> wrote:
> Yes, we should keep the existing code view. It is useful for simple cases, > especially with dag versioning, but let's do no more than that. > > On Wed, Jul 22, 2026 at 3:57 AM Amogh Desai <[email protected]> wrote: > > > Agreed. > > > > The code view is particularly useful for relatively simple cases and > > personally I use it > > a bit for viewing the diff from last versions. For now, I agree that it's > > OK to not show java > > SDK based dags. > > > > Thanks & Regards, > > Amogh Desai > > > > > > On Wed, Jul 22, 2026 at 1:08 PM Shahar Epstein <[email protected]> > wrote: > > > > > Thanks TP (and Jason!) for putting it into discussion, > > > > > > I'm fine with the ADR in its current form and understand the > > considerations > > > for limiting it in present time. > > > Hopefully we could come up with a more comprehensive resolution for > that > > > matter in later stage. > > > > > > > > > Shahar > > > > > > On Wed, Jul 22, 2026 at 12:26 AM Tzu-ping Chung via dev < > > > [email protected]> wrote: > > > > > > > Hi all, > > > > > > > > This came from the PR https://github.com/apache/airflow/pull/70059 > > > > > > > > During AIP-108 testing, users asked whether the UI Code view for > > > > mixed-language authoring (a Python file with @task.stub tasks backed > by > > > an > > > > e.g. Java SDK artifact) could also show the Lang-SDK-side source, > e.g. > > > as a > > > > second tab next to the Python file. > > > > > > > > We are leaning toward not supporting this feature as a deliberate > > design > > > > decision *at this moment*. My (personal) main reasoning is the > current > > > code > > > > view isn’t really that useful in practice to begin with. It’s usable > > for > > > > very simple dags, but in production systems, where the Python file > only > > > > serves as a top-level entry point that just imports things defined in > > > other > > > > modules, those "real" code can’t be shown. This is arguably even > worse > > in > > > > Java-land, where you’re REQUIRED to define a public class in a > separate > > > > file in the first place. > > > > > > > > In the practical scenario, the only way to display somewhat useful > code > > > > (instead of just a class that repeats task definitions as the stubs), > > > we’d > > > > need to collect all the source files that the JAR containing task > > > > definition can reach. This bloats the DagCode table significantly. > Even > > > > worse, the value of doing this is *still* quite limited. The main > > reason > > > > people want the Java SDK in the first place is to be able to call > > > existing > > > > Java functions, potentially deployed by other teams in bytecode form, > > > > without a source to display at all. > > > > > > > > The view is still not very useful if we take a step back. For a real > > > > mixed-language case, where you can mix more than one, or even two > > > > languages, a cheaper variant showing only the entrypoint file per > > > Lang-SDK, > > > > still falls short. But if we display everything everywhere, we’re > back > > to > > > > bloating the table. > > > > > > > > If we intend to improve the situation, I would suggest we fix this > for > > > ALL > > > > the cases, starting from pure Python ones that import other Python > > files. > > > > The concept of Dag Bundles already paves the way for this, and > language > > > SDK > > > > support comes naturally after it. However, this is a pretty > significant > > > > undertaking on its own, and should be its own project with AIPs and > > > stuff. > > > > In the meantime, it would be a waste of effort creating an > artificially > > > > "nice" feature of limited value (if any) in practice for language > SDKs. > > > > > > > > The proposal is therefore > > > > > > > > * Keep the status quo at this moment: the code view shows only the > > Python > > > > Dag file. Language Java SDK docs state this explicitly. > > > > * Merge #70059 to record the decision. > > > > * Close #67260 (issue on view Language SDK code) as won't-fix, > > > referencing > > > > #70059. > > > > > > > > Feedback welcome. In particular, if you have a concrete use case > where > > an > > > > entrypoint-only view would carry its weight, we'd like to hear it. > > > > Otherwise we'll proceed with the ADR by lazy consensus. > > > > > > > > Also feel free to send me a message if you would like to discuss > > further > > > > on a better-code-view project. It probably should stay out of this > > > thread, > > > > however. If you prefer using the mailing list, please open a new > thread > > > > instead. > > > > > > > > Best, > > > > TP > > > > > > > > > > > > -- > > > > > > > > Some useful links: > > > > > > > > - ADR PR: https://github.com/apache/airflow/pull/70059 > > > > - Original ask: https://github.com/apache/airflow/issues/67260 > > > > - AIP-108: https://cwiki.apache.org/confluence/x/pY4mGQ > > > > - AIP-85 (DagImporter): https://cwiki.apache.org/confluence/x/_Q7OEg > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > >
