I think that trying to *forbid* this is really not Pythonic. A more
appropriate way would be to have import paths ("from airflow.internals"),
docstrings, and warnings (via the silenceable warnings module) indicating
which APIs are "internal" (i.e., subject to change even in patch versions).
That is, let's try to build warning signs rather than walls.On Mon, Feb 24, 2020 at 9:27 AM Jarek Potiuk <[email protected]> wrote: > I would like to open another discussion :) .. Following recent discussions > about the "DAG" being an important internal API of Airflow but also > following this post: > > https://medium.com/maisonsdumonde/road-to-add-form-for-airflows-dag-1dcf2e7583ef > > I think we should consider marking certain internal parts of Airflow > classes as a stable/formal API for DAG writers. I think we can do it fairly > easily with AST parsing while importing the DAGs and first deprecating in > 2.0 and then forbidding in 2.1 using internal objects/methods APIs that we > do not consider as "stable". I'd go for "allowed list" and forbidding > everything else. > > I have no list of the "proposed" stable APIs yet, but I wanted to check if > others think that this is a good idea as well. > > WDYT? > > J. > > -- > > Jarek Potiuk > Polidea <https://www.polidea.com/> | Principal Software Engineer > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/> >
