Skip to content

Stop adding repos to sys.path (set experimental_python_import_all_repositories to false) #2943

Open
@rickeylev

Description

@rickeylev

Right now, repo roots are added to sys.path. This is problematic for a variety of reasons

  • It causes the repos with external pip deps to end up on sys.path, which are just spam and just cause problems.
  • For the main repo and other external repos, they should be using the imports attribute on their public targets instead.

The situation is a bit complicated because the flag (and its default) are defined in bazel, while the implementation is in rules_python. Also, there's a decent reliance on this behavior in the broader ecosystem because it's been around for a long time, even though it was never a good idea to rely on it. With the advent of bzlmod, the reliance would only get worse (adding repo roots to path is helpful under bzlmod).

I think the venv site-packages work we've done will help this problem -- it allows mapping an arbitrary directory into site-packages, which should make materializing external repos under arbitrary names more flexible.

I think the steps needed are:

  1. Add a flag in rules_python to replace the bazel-builtin one.
  2. Let bazel remove their flag when appropriate. Note that doing this will force users to upgrade to a version of rules_python with (1)
  3. Disable adding repo roots for pip-generated repos. Do this by adding a marker file in the repo root (under the hood, these repos are added by doing listdir() on the runfiles root)
  4. Add an allowlist for which external repos are added to sys.path. We don't control non-pip repos, so need another mechanism to specify this. A flag that points to a target with repo names to allow being added onto sys.path is good compromise.
  5. Disable the behavior by default; users can use the allowlist to aid migration.
  6. Eventually remove the allowlist.

The old builtin flag (--foo) can be mapped to the new repo-flag (--@bla//:foo) using --flag_alias

This is the rules_python side of bazelbuild/bazel#2636

Metadata

Metadata

Assignees

No one assigned

    Labels

    cleanupTech debt, resolving it improves our own velocitycore-rulesIssues concerning core bin/test/lib rules

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions