Don't include pyc files as part of the hermetic toolchain by tomgr · Pull Request #713 · bazel-contrib/rules_python

Don't include pyc files as part of the hermetic toolchain by tomgr · Pull Request #713 · bazel-contrib/rules_python

pyc files don't appear to be generated deterministically, so including
them as part of the :files filegroup means that actions that use the
hermetic toolchain do not have deterministic hashes, and so bazel
needlessly re-executes them. This can be seen when using bazel together
with a remote cache: builds on separate machines will generate pyc files
with different hashes, leading to cache misses.

This was referenced

Jul 12, 2022

keith mentioned this pull request

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

phst mentioned this pull request

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

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

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

kyakdan added a commit to CodeIntelligenceTesting/oss-fuzz that referenced this pull request

This is a requirement for one dependency. Otherwise, we get the error:
"The current user is root, please run as non-root when using
the hermetic Python interpreter. See
bazel-contrib/rules_python#713."

kyakdan added a commit to CodeIntelligenceTesting/oss-fuzz that referenced this pull request

This is a requirement for one dependency. Otherwise, we get the error:
"The current user is root, please run as non-root when using
the hermetic Python interpreter. See
bazel-contrib/rules_python#713."

kyakdan added a commit to CodeIntelligenceTesting/oss-fuzz that referenced this pull request

This is a requirement for one dependency. Otherwise, we get the error:
"The current user is root, please run as non-root when using
the hermetic Python interpreter. See
bazel-contrib/rules_python#713."

fweikert added a commit to fweikert/bazel that referenced this pull request

copybara-service bot pushed a commit to bazelbuild/bazel that referenced this pull request

github-merge-queue bot pushed a commit to bazelbuild/bazel that referenced this pull request

Our CI fails to build Bazel, producing this error: "The current user is
root, please run as non-root when using the hermetic Python interpreter.
See bazel-contrib/rules_python#713."

The workaround was suggested at
bazel-contrib/rules_python#1169 (comment)

Closes #24549.

PiperOrigin-RevId: 702362811
Change-Id: Ib6d4da1e09fd2b7dfd68af02bbb0eb997e8f427c

Co-authored-by: Florian Weikert <fwe@google.com>

Wyverald added a commit that referenced this pull request

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

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

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

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

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

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

…-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>

cburchert added a commit to cburchert/emsdk that referenced this pull request