You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2022/09/11 22:22:47 UTC

[GitHub] [airflow] potiuk commented on pull request #25829: Fix templating for KubernetesPodOperator env_vars field

potiuk commented on PR #25829:
URL: https://github.com/apache/airflow/pull/25829#issuecomment-1243055014

   You have a conflict to solve (that's first).
   
   While I agree the problem is important to solve, I think string and using literal_eval is just wrong.
   We are talking about passing dictionary of strings - and this dictionary of strings should be passed to EnvVars not string. Is it possible? Can you do it this way while still being templatised in your case?
   
   I think literal_eval has one big problem with user-input data - namely that you are never sure what type of object you will get - it can be string, list, dict etc - depending on the data passed by the user as input. And this is - I believe what @uranusjr refers to. Have you tests what happens if the user passes a Tuple or Dict of Dict of Strings? I think not. That's why literal evel is often a shortcut that should be avoided - even if it is used in a few places - I'd avoid it unless you want to handle a truly generic case that you cannot foresee.
   
   This case is DIFFERENT. you have a variable number of entries Dict[str, str] tp pass.  Is it possible to work out a scheme where you can only receive and validate that as an input from the user?


-- 
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-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org