TA貢獻1780條經驗 獲得超1個贊
處理此問題的最佳方法是確保您的導入范圍在您的項目范圍內；例如，而不是from common import foo，而不是做from drake_bazel_external.common import foo。
以下是使用 Python 執行此操作的示例 Bazel 項目的片段：
https://github.com/EricCousineau-TRI/repro/blob/39f79009a2e89b987f072276d1921a282f63e6a1/python/bazel_py_example/mid/py3_bin.py#L3
對于根本原因，這是我嘗試用更多輸出來檢測您的重現，固定到[email protected]：
drake_bazel_external/apps/bar.py（分支機構）
下面是 Python 路徑的預覽，它證實了您所看到的內容：
path:
{source_tree}/apps
{runfiles}
{runfiles}/drake/bindings
{runfiles}/lcmtypes_bot2_core/lcmtypes
{runfiles}/lcmtypes_bot2_core
{runfiles}/lcmtypes_robotlocomotion/lcmtypes
{runfiles}/lcmtypes_robotlocomotion
{runfiles}/meshcat_python/src
{runfiles}/spdlog
{runfiles}/meshcat_python
{runfiles}/lcm
{runfiles}/ignition_math
{runfiles}/drake
{runfiles}/drake_external_examples
/usr/lib/python36.zip
/usr/lib/python3.6
/usr/lib/python3.6/lib-dynload
/usr/lib/python3/dist-packages
common: {runfiles}/drake/common/__init__.py
最終，這是預期的行為。這是德雷克問題和一個相關bazelbuild問題：
https://github.com/RobotLocomotion/drake/issues/7871
https://github.com/bazelbuild/bazel/issues/7653
最好的方法是使用特定于項目的導入。現在，嘗試通過使用更具體的導入來避免這種情況。
我將重新打開 Drake 問題，但會保持低優先級，因為有更好的解決方案 (IMO)，并且需要更多的基礎設施工作才能實現。
謝謝！
編輯：具體來說，最嚴重地絆倒你的例子的是 Bazel 正在生成@drake//common:__init__.py. 它只是由于legacy_create_init標志以及我們想要文件的事實而生成的libdrake_marker.so。
仍然有一個事實drake（在其他存儲庫中）完全在 Python 上。
編輯 2：根據 Jeremy 的要求提出新問題：https ://github.com/RobotLocomotion/drake/issues/13320
舉報