potiuk commented on PR #28520: URL: https://github.com/apache/airflow/pull/28520#issuecomment-1361358962
> Well, that's true. But then again, its most likely the same case for the other installation flags used in the entrypoint for installations. Isn't it better to pick one approach and stick with it? IMHO if there is already an environment variable for installation options why not use it ? it merely feels like this environment variable was forgotten in this specific line. Not really. The `ADDITIONAL_PIP_INSTALL_FLAGS` is regular flag to be used by regular users of the dockerfile for building a new image using `docker build`. This is why it has no `_` in front. The PIP_PROGRESS_BAR="on" is also a build option (but due to being the standard PIP veriable it will also be effective at runtime - but that's ok because it is just defining the progres behaviour. This "development iteration" workflow with `_PIP_ADDITIONAL_REQUIREMENTS`is specifically foreseen for users like you who are not rebuilding the image every time they change something, but want to develop quickly and install/update new packages without going through the hassle of building the image (Hence `_` in front to indicate it is temporary and not production). It even prints warning when you use it. Wen they finish that phase and proceed to to actual instlallation they should extend or customize the image and build their own (and then you can also ADDITIONAL_PIP_INSTALL_FLAGS). Mixing those two is bad idea - I cannot imagine you want ADDITIONAL_PIP_INSTALL_FLAGS it contain "127.0.0.1:" in the finally built image when you build it for production for example. Simply speaking `ADDITIONAL_PIP_INSTALL_FLAGS` is a "production docker build variable" and `_PIP_ADDITIONAL_REQUIREMENTS` is "development docker run variable". Completely different usages. What's even more - we want to have the "dev runtime" to come with somewhat of a friction so that it is not used in final deployment (for example that's why we print the warning) - because it causes **plenty** of problems if you use it there. In this case using the `pip` env variables makes perfect sense - because you need to know them and pass them when you do docker-run. > Sure thing, in place in particular in the docs directory that should be relevant for this? https://airflow.apache.org/docs/docker-stack/entrypoint.html#installing-additional-requirements - just use "Suggest a chnage" button and PR will be opened for you in the righ source. > Also the question that arise is how to configure the cache - via a pip environment configuration? From the docs pointed out by @Taragolis : `PIP_<UPPER_LONG_NAME>`. So `PIP_INDEX_URL` and `PIP_TRUSTED_HOST` I guess. You can specify any `pip` flag this way. -- 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]
