Filing a bug here so that we don't forget to get rid of Yet Another Command Line Option.
Ok I won't manage to fix everything for that change so I am rescheduling it for 0.6
cc @vsethia and @ahumesky
FYI, this change will heavily affect the Android testing infrastructure (android_device) that is being open sourced at https://github.com/google/android-testing-support-library. It is mostly in Python and has several external repositories that it imports from.
This is an interesting situation, in that we know we want to ban the old behavior and we even already have a flag to do it, but the new behavior doesn't have a complete story yet. See #7067.
In the meantime, we might go ahead and rename this to --incompatible_repo_roots_are_not_on_pythonpath (inverting the meaning) and make it available as an incompatible change, even though flipping it is blocked on more feature work being done. :-/
I just ran into an issue running Bazel that I tracked down to this flag.
I am packaging the PY2 and PY3 version of an app together, allowing us to start testing the PY3 version on staging environments while still running the PY2 version in prod.
When this flag is set to true, the PY3 version has PY2 dependencies in its PYTHONPATH, causing issues starting the application (the exact issue being that PY2 deps have the enum34 package which causes issues when using Python 3).
So just a note that this flag can cause some very unexpected behaviours.
Most helpful comment
I just ran into an issue running Bazel that I tracked down to this flag.
I am packaging the PY2 and PY3 version of an app together, allowing us to start testing the PY3 version on staging environments while still running the PY2 version in prod.
When this flag is set to true, the PY3 version has PY2 dependencies in its PYTHONPATH, causing issues starting the application (the exact issue being that PY2 deps have the enum34 package which causes issues when using Python 3).
So just a note that this flag can cause some very unexpected behaviours.