potiuk commented on PR #55894: URL: https://github.com/apache/airflow/pull/55894#issuecomment-3409863947
> @uranusjr can you explain what you refer to by the "original code" here? I believe what @uranusjr meant is that now adding the path happens inside DagBag, and potentially DagBag might be used in a number of places, so adding a path for those cases (even if it is removed) can have some side effects (modules loaded from a path that is no longer available on sys.path. The "orignal" way (if I interpret it correctly) addded the sys.path entry not in the "DagBag" - but outside - in the code that we "knew" we don't care about side-effects (for example in dag file processor parsing is done in a forked interpreter, and the interpreter exists after the Dag is serialized). Again - if I am right - maybe a better solution that is both DRY and side-effect frree for regular DagBag usage, might be another class (`DagBagWithExtraBundlePath` - I know, bad name) which would extend from the DagBag, do the try/finally around DagBag parse in it's own parse - and use that class specifically in those places that need to extend sys.path. Is that good interpretation and proposal @uranusjr ? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
