python_repository: Exclude pycache files by illicitonion · Pull Request #907 · bazel-contrib/rules_python

@illicitonion

Some of these are missing from the upstream python distributions, and
when they are, if running as root, this causes the files to be generated
the first time their associated .py file is evaluated, causing analysis
and execution cache misses due to extra files matching the repository glob.

illicitonion added a commit to illicitonion/rules_python that referenced this pull request

Feb 1, 2023

This was referenced

Jun 12, 2023

phst added a commit to phst/rules_elisp that referenced this pull request

Jan 18, 2024

@phst phst mentioned this pull request

Jan 18, 2024

phst added a commit to phst/rules_elisp that referenced this pull request

Jan 18, 2024

phst added a commit to phst/rules_elisp that referenced this pull request

Jan 18, 2024

phst added a commit to phst/rules_elisp that referenced this pull request

Jan 19, 2024

Wyverald added a commit that referenced this pull request

Feb 28, 2025
Currently, by default, rules_python immediately fails when Bazel is run as root. The reasoning behind this involves .pyc files being generated for hermetic toolchains when they're first used, causing cache misses; to work around this, rules_python opts to make the toolchain installation directory read-only, but running Bazel as root would circumvent this. So rules_python actively detects if the current user is root, and hard fails. This check can be disabled by the root module by setting `python.override(ignore_root_user_error=True)`. (See more context in the linked issues/PRs.)

This causes a reverberating effect across the Bazel ecosystem, as rules_python is essentially a dependency of every single Bazel project through protobuf. Effectively, any Bazel project wishing to run as root need to add the override tag above, even if they don't have anything to do with Python at all.

This PR changes the default value of the `ignore_root_user_error` to True instead. Besides, it now unconditionally tries to make the toolchain installation directory read-only, and only outputs a warning if it's detected that the current user is root.

See previous discussions at #713, #749, #907, #1008, #1169, etc.

Fixes #1169.

Wyverald added a commit that referenced this pull request

Feb 28, 2025
Currently, by default, rules_python immediately fails when Bazel is run as root. The reasoning behind this involves .pyc files being generated for hermetic toolchains when they're first used, causing cache misses; to work around this, rules_python opts to make the toolchain installation directory read-only, but running Bazel as root would circumvent this. So rules_python actively detects if the current user is root, and hard fails. This check can be disabled by the root module by setting `python.override(ignore_root_user_error=True)`. (See more context in the linked issues/PRs.)

This causes a reverberating effect across the Bazel ecosystem, as rules_python is essentially a dependency of every single Bazel project through protobuf. Effectively, any Bazel project wishing to run as root need to add the override tag above, even if they don't have anything to do with Python at all.

This PR changes the default value of the `ignore_root_user_error` to True instead. Besides, it now unconditionally tries to make the toolchain installation directory read-only, and only outputs a warning if it's detected that the current user is root.

See previous discussions at #713, #749, #907, #1008, #1169, etc.

Fixes #1169.

Wyverald added a commit that referenced this pull request

Feb 28, 2025
Currently, by default, rules_python immediately fails when Bazel is run as root. The reasoning behind this involves .pyc files being generated for hermetic toolchains when they're first used, causing cache misses; to work around this, rules_python opts to make the toolchain installation directory read-only, but running Bazel as root would circumvent this. So rules_python actively detects if the current user is root, and hard fails. This check can be disabled by the root module by setting `python.override(ignore_root_user_error=True)`. (See more context in the linked issues/PRs.)

This causes a reverberating effect across the Bazel ecosystem, as rules_python is essentially a dependency of every single Bazel project through protobuf. Effectively, any Bazel project wishing to run as root need to add the override tag above, even if they don't have anything to do with Python at all.

This PR changes the default value of the `ignore_root_user_error` to True instead. Besides, it now unconditionally tries to make the toolchain installation directory read-only, and only outputs a warning if it's detected that the current user is root.

See previous discussions at #713, #749, #907, #1008, #1169, etc.

Fixes #1169.

Wyverald added a commit that referenced this pull request

Feb 28, 2025
Currently, by default, rules_python immediately fails when Bazel is run as root. The reasoning behind this involves .pyc files being generated for hermetic toolchains when they're first used, causing cache misses; to work around this, rules_python opts to make the toolchain installation directory read-only, but running Bazel as root would circumvent this. So rules_python actively detects if the current user is root, and hard fails. This check can be disabled by the root module by setting `python.override(ignore_root_user_error=True)`. (See more context in the linked issues/PRs.)

This causes a reverberating effect across the Bazel ecosystem, as rules_python is essentially a dependency of every single Bazel project through protobuf. Effectively, any Bazel project wishing to run as root need to add the override tag above, even if they don't have anything to do with Python at all.

This PR changes the default value of the `ignore_root_user_error` to True instead. Besides, it now unconditionally tries to make the toolchain installation directory read-only, and only outputs a warning if it's detected that the current user is root.

See previous discussions at #713, #749, #907, #1008, #1169, etc.

Fixes #1169.

Wyverald added a commit that referenced this pull request

Feb 28, 2025
Currently, by default, rules_python immediately fails when Bazel is run as root. The reasoning behind this involves .pyc files being generated for hermetic toolchains when they're first used, causing cache misses; to work around this, rules_python opts to make the toolchain installation directory read-only, but running Bazel as root would circumvent this. So rules_python actively detects if the current user is root, and hard fails. This check can be disabled by the root module by setting `python.override(ignore_root_user_error=True)`. (See more context in the linked issues/PRs.)

This causes a reverberating effect across the Bazel ecosystem, as rules_python is essentially a dependency of every single Bazel project through protobuf. Effectively, any Bazel project wishing to run as root need to add the override tag above, even if they don't have anything to do with Python at all.

This PR changes the default value of the `ignore_root_user_error` to True instead. Besides, it now unconditionally tries to make the toolchain installation directory read-only, and only outputs a warning if it's detected that the current user is root.

See previous discussions at #713, #749, #907, #1008, #1169, etc.

Fixes #1169.

github-merge-queue bot pushed a commit that referenced this pull request

Mar 3, 2025
Currently, by default, rules_python immediately fails when Bazel is run
as root. The reasoning behind this involves .pyc files being generated
for hermetic toolchains when they're first used, causing cache misses;
to work around this, rules_python opts to make the toolchain
installation directory read-only, but running Bazel as root would
circumvent this. So rules_python actively detects if the current user is
root, and hard fails. This check can be disabled by the root module by
setting `python.override(ignore_root_user_error=True)`. (See more
context in the linked issues/PRs.)

This causes a reverberating effect across the Bazel ecosystem, as
rules_python is essentially a dependency of every single Bazel project
through protobuf. Effectively, any Bazel project wishing to run as root
need to add the override tag above, even if they don't have anything to
do with Python at all.

This PR changes the default value of the `ignore_root_user_error` to
True instead. Besides, it now unconditionally tries to make the
toolchain installation directory read-only, and only outputs a warning
if it's detected that the current user is root.

See previous discussions at #713, #749, #907, #1008, #1169, etc.

Fixes #1169.

---------

Co-authored-by: Richard Levasseur <rlevasseur@google.com>

dcode pushed a commit to dcode/rules_python that referenced this pull request

Mar 3, 2025
…-contrib#2636)

Currently, by default, rules_python immediately fails when Bazel is run
as root. The reasoning behind this involves .pyc files being generated
for hermetic toolchains when they're first used, causing cache misses;
to work around this, rules_python opts to make the toolchain
installation directory read-only, but running Bazel as root would
circumvent this. So rules_python actively detects if the current user is
root, and hard fails. This check can be disabled by the root module by
setting `python.override(ignore_root_user_error=True)`. (See more
context in the linked issues/PRs.)

This causes a reverberating effect across the Bazel ecosystem, as
rules_python is essentially a dependency of every single Bazel project
through protobuf. Effectively, any Bazel project wishing to run as root
need to add the override tag above, even if they don't have anything to
do with Python at all.

This PR changes the default value of the `ignore_root_user_error` to
True instead. Besides, it now unconditionally tries to make the
toolchain installation directory read-only, and only outputs a warning
if it's detected that the current user is root.

See previous discussions at bazel-contrib#713, bazel-contrib#749, bazel-contrib#907, bazel-contrib#1008, bazel-contrib#1169, etc.

Fixes bazel-contrib#1169.

---------

Co-authored-by: Richard Levasseur <rlevasseur@google.com>