python: stop passing no-user flag on installation

[dtrodrigues]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?
• Have you successfully run brew man locally and committed any changes?

---

--no-user is not a supported end-user flag in pip, and is explicitly non-documented: pypa/pip#8977 (comment)
pypa/pip@87bb4f9

It was added as part of building python packages from source in case a user's configuration specified --user installs due to the fact that you cannot do a --user install within a venv:

$ pip install --user foo
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

Recent versions of pip fall back to a user installation if site-packages is not writeable. Additionally, when building a formula, only the global and site pip configurations are looked at -- the user configuration is empty within ..../.brew_home/, so this change in Homebrew doesn't impact users who have user installs as a local configuration.

[BrewTestBot]

Review period will end on 2021-02-22 at 18:07:50 UTC.

[Rylan12]

I agree. If --no-user is "not a supported end-user flag" we shouldn't use it.

Separately, is it still possible for a user's global pip configuration file to affect builds? Should/can we handle this? I'm not just thinking about the --user or --no-user issue. Are there other settings that could be set in one of these that would affect the build? It's possible that we manually override everything that needs to be controlled, I'm just not familiar enough to judge.

[dtrodrigues]

Yes - a user's global pip configuration does affect builds, but not their local configuration (since $HOME is replaced by .brew_home) or their environment variables (filtered out).

Running on macOS, during a build from source (for example for the jc python formula), the pip configuration is looked for in

global:
  /Library/Application Support/pip/pip.conf, exists: False
site:
  /opt/homebrew/Cellar/jc/1.14.3/libexec/pip.conf, exists: False
user:
  /private/tmp/jc-20210219-35155-hhi3f/jc-1.14.3/.brew_home/.pip/pip.conf, exists: False
  /private/tmp/jc-20210219-35155-hhi3f/jc-1.14.3/.brew_home/.config/pip/pip.conf, exists: False

On Linux, it is

global:
  /etc/xdg/pip/pip.conf, exists: False
  /etc/pip.conf, exists: False
site:
  /home/linuxbrew/.linuxbrew/Cellar/jc/1.14.3/libexec/pip.conf, exists: False
user:
  /tmp/jc-20210220-30481-ijb3gc/jc-1.14.3/.brew_home/.pip/pip.conf, exists: False
  /tmp/jc-20210220-30481-ijb3gc/jc-1.14.3/.brew_home/.config/pip/pip.conf, exists: False

There are some settings which can be beneficial when passed into the Homebrew python building of a formula from source (see Homebrew/discussions#863). The only way to manipulate those is by changing the global config file, which typically requires administrative privileges.

The cases in which we want to allow a user to influence their formula builds and how much is an open question and a tradeoff between reproducibility and customization.

FWIW, the --isolated flag for pip doesn't do anything for us since it only ignores user configurations, and those are already ignored -- it doesn't isolate from site or global configurations: pypa/pip#3828

[Rylan12]

Gotcha, thanks

[MikeMcQuaid]

Makes sense 👍🏻

[BrewTestBot]

Review period ended.