potiuk commented on PR #35360: URL: https://github.com/apache/airflow/pull/35360#issuecomment-1789737980
See my follow-up in https://github.com/apache/airflow/discussions/31974#discussioncomment-6203057 My point is not that DAG should be final, but when you extend it you need to understand what you are doing. `dag.py` has 4000+ lines and there is quite a bit of dark-python-magic in. Simply the thought that you can extend DAG without understanding how it all works (with decorators using it, mapped tasks, metaclass handing apply_defaults, 9 dunder methods, SerializedDAG extending from it and plenty of other things you see when you open `dag.py` file is well, SCARY. You don't extend such huge class with metaclasses, about 150 metods, 9 dunder methods without REALLY knowing what you are doing. And the user seem to be complaining that we have no documentation that explains that. So yes, while I think maybe a documentation is needed, the I think the users should contribute it - those who want to extend it, have a good reason and explain the use case and implement it (maybe with our help) AND CONTRIBUTE THE DOCS BACK. I don't think WE (maybe @hussein-awala who did it as a user is) should be doing it - because this should really come from the needs of our users on how they are extending it. As maintainers - if we have not foreseen the ways DAG can be extended , then it means it is not meant to be extended. But if our users have a need and do it and achieve something good with it - it's cool if they contribute it back (which BTW we might find as a good idea to not document but incorporate in our DAG implementation). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
