Add an opt-out for the “running as root” warning · Issue #10556 · pypa/pip (original) (raw)

Comments

@hholst80

potiuk added a commit to apache/airflow that referenced this issue

Jan 22, 2022

@potiuk

PIP produces a warning when root user is used to run pip install. This is done for a good reason - because installing PIP this way clashes with a number of distro-managed python packages.

The warning cannot be disabled even if our use case is legitimate as has been extensively discussed in pypa/pip#10556.

However, the advice given by the warning is a bit misleading - it suggests to use virtualenv, but since this is considered a bad practice for container building and because we need to create virtualenvs dynamically inside the image, using virtualenv is a bad solution for us. It's been attempted in #19189 and failed.

Instead we create an airflow user and use PIP_USER="true" which installs all dependencies in build segment to ~/.local folder from where we can copy it to the main image.

That get rids of the warning and at the same time allows us to keep the best practices of building the images.

(cherry picked from commit 3feb057)

potiuk added a commit to apache/airflow that referenced this issue

Jan 22, 2022

@potiuk

There was some "junk" output generated by the scripts that are used in Airflow image building. The junk has been cleaned up so that no unnecessary warnings are generated.

This change includes:

Separated out from #20238

(cherry picked from commit 4d33ebf)

jedcunningham pushed a commit to apache/airflow that referenced this issue

Jan 27, 2022

@potiuk @jedcunningham

PIP produces a warning when root user is used to run pip install. This is done for a good reason - because installing PIP this way clashes with a number of distro-managed python packages.

The warning cannot be disabled even if our use case is legitimate as has been extensively discussed in pypa/pip#10556.

However, the advice given by the warning is a bit misleading - it suggests to use virtualenv, but since this is considered a bad practice for container building and because we need to create virtualenvs dynamically inside the image, using virtualenv is a bad solution for us. It's been attempted in #19189 and failed.

Instead we create an airflow user and use PIP_USER="true" which installs all dependencies in build segment to ~/.local folder from where we can copy it to the main image.

That get rids of the warning and at the same time allows us to keep the best practices of building the images.

(cherry picked from commit 3feb057)

jedcunningham pushed a commit to apache/airflow that referenced this issue

Jan 27, 2022

@potiuk @jedcunningham

There was some "junk" output generated by the scripts that are used in Airflow image building. The junk has been cleaned up so that no unnecessary warnings are generated.

This change includes:

Separated out from #20238

(cherry picked from commit 4d33ebf)

potiuk added a commit to potiuk/pip that referenced this issue

Mar 26, 2022

@potiuk

This PR implements the flag that allows to disable the root warning when using pip to install packages. While there are differing opinions on this, it seems that the final decision is to lean forward to implement a long and not very easily discoverable flag to accommodate the minority of users who know what they are doing and using root installation to - for example build optimized Dockerfiles.

Even approval, and eventually an adoption of PEP 668 to make the problem largely go away is still a long time to go, so as discussed in pypa#10556 (comment) this PR adds a long and non-user friendly flag to handle the situation.

Fixes: 10556

potiuk added a commit to potiuk/pip that referenced this issue

Mar 26, 2022

@potiuk

This PR implements the flag that allows to disable the root warning when using pip to install packages. While there are differing opinions on this, it seems that the final decision is to lean forward to implement a long and not very easily discoverable flag to accommodate the minority of users who know what they are doing and using root installation to - for example build optimized Dockerfiles.

Even approval, and eventually an adoption of PEP 668 to make the problem largely go away is still a long time to go, so as discussed in pypa#10556 (comment) this PR adds a long and non-user friendly flag to handle the situation.

Fixes: pypa#10556

potiuk added a commit to potiuk/pip that referenced this issue

Mar 26, 2022

@potiuk

This PR implements the flag that allows to disable the root warning when using pip to install packages. While there are differing opinions on this, it seems that the final decision is to lean forward to implement a long and not very easily discoverable flag to accommodate the minority of users who know what they are doing and using root installation to - for example build optimized Dockerfiles.

Even approval, and eventually an adoption of PEP 668 to make the problem largely go away is still a long time to go, so as discussed in pypa#10556 (comment) this PR adds a long and non-user friendly flag to handle the situation.

Fixes: pypa#10556

potiuk added a commit to potiuk/pip that referenced this issue

Mar 26, 2022

@potiuk

This PR implements the flag that allows to disable the root warning when using pip to install packages. While there are differing opinions on this, it seems that the final decision is to lean forward to implement a long and not very easily discoverable flag to accommodate the minority of users who know what they are doing and using root installation to - for example build optimized Dockerfiles.

Even approval, and eventually an adoption of PEP 668 to make the problem largely go away is still a long time to go, so as discussed in pypa#10556 (comment) this PR adds a long and non-user friendly flag to handle the situation.

Fixes: pypa#10556

potiuk added a commit to potiuk/pip that referenced this issue

Mar 26, 2022

@potiuk

This PR implements the flag that allows to disable the root warning when using pip to install packages. While there are differing opinions on this, it seems that the final decision is to lean forward to implement a long and not very easily discoverable flag to accommodate the minority of users who know what they are doing and using root installation to - for example build optimized Dockerfiles.

Even approval, and eventually an adoption of PEP 668 to make the problem largely go away is still a long time to go, so as discussed in pypa#10556 (comment) this PR adds a long and non-user friendly flag to handle the situation.

Fixes: pypa#10556

@github-actions github-actions bot locked as resolved and limited conversation to collaborators

May 8, 2022