r-richmond commented on pull request #11950: URL: https://github.com/apache/airflow/pull/11950#issuecomment-827197437
>For Python 3.9 I think I will simply go with the #15515 as in order to merge it there will be one more "tricky" point which is to make sure that Python 3.9 is also built in the "build images" workflow. Once this will be merged, I think it will have all the changes from that PR so I think we will be able to close this one (I will be happy to make you co-author of the #15515 :). In that case I'll close this PR out. Thanks for tackling the extra effort for 3.9. As far as co-author goes I've already my Contributor label from other PRS so no need to add me as a co-author for that one. Besides you did a lot of work in this pr as well. >PIP 21 (PR to be merged in #15513) already has a working resolver that is detecting conflicts much better and we will continue using it to prevent conflicts once it is merged Oh I'm not familiar with the new resolver. As long as it can detect conflicts this would address my feedback / concern. >AFAIK (and please correct me if I am wrong) neither Poetry nor PIPEnv bring anything more, actually the workflows they support are limiting. They are more opinionated and allow either the library approach (everything as open as possible) or the application one (everything fixed with poetry/pipenv .lock file) >However I am really open to add "support" for people who are using Poetry or PIPenv. I know there are many users of poetry/pipenv out there. If you are one of the poetry/pipenv users and could write a nice HowTo - how to take Airflow constraints and install airflow with Poetry and Pipenv I am all ears. So I'm no expert and my point of view is very heavy from the Application side. So from that point of view the big thing pipenv does is take open-ended requirements and spit out an explicit list of things installed. The nice thing about this is you can pin versions in the Pipfile and leave others open which is much more flexible than a normal frozen requirements. (And of course the big thing reproducible builds). The only thing fragile here is that pipenv and poetry won't let you lock if an invalid set of requirements slip into airflow, Historically this has happened several times https://github.com/apache/airflow/issues/13093 https://github.com/apache/airflow/issues/14145 https://github.com/apache/airflow/issues/13558 with airflow but if as you said above the new Pip resolver detects these we should be good. Anyways I could write a small guide on using Pipenv with airflow. Whats interesting is that there is nothing special about airflow + pipenv so I don't know how much of it would be novel but if you think it would help I'd be happy to. Where do you think it should go in the repo? -- 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. For queries about this service, please contact Infrastructure at: [email protected]
