potiuk commented on PR #25780: URL: https://github.com/apache/airflow/pull/25780#issuecomment-1228889456
I think I addressed all comments (thanks for VERY THOROUGH docs review @o-nikolas and @ashb ). I think I figured out a good proposal that fits very well both - requirements of being similar to virtualenv and being "correct" in terms of not having to use virtualenv. My proposal (and it's already updated in the PR) is: * PythonOtherenvOperator * @task.otherenv decorator I think this addresses all the concerns, it is short, easy to remember and use and also has very close resemblance to PythonVirtualenvOperator to show that it is closer to it than to PythonOperator and it does not imply Virtualenv. Few doubts I had (and I made some choices that could be changed still): * PythonOtherEnvOperator vs PythonOtherenvOperator -> I think the latter is better even if slightly less "correct" - it also matches well the decorator (we have no casing in decorator by convention) * @task.python_otherenv vs. @task.otherenv -> I think the latter is better: shorter and more close to @task.virtualenv too. * still there is one reference to virtualenv - we have ``virtualenv_string_args`` still created as 'global' variable accessible in the task. Changing it would be backwards-incompatible, and I think it's not worth to handle it differently. Let me know what you think @o-nikolas @uranusjr @ashb. Does it look `good-enough` for all of you :) -- 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]
