<#22458 With `ambiguity_resolution = "by_source_ro...
# github-notifications
c
#22458 With `ambiguity_resolution = "by_source_root"`, target `/a/b/c` does not prefer `/a/b:x` over `/a/c:x`. Issue created by pimdh Describe the bug See the modified python example at pimdh/pants-example-python#1 In it,
helloworld/translator/translator.py
depends on
rich
, which is defined in
helloworld/translator/BUILD
and
helloworld/greet/BUILD
. With
ambiguity_resolution = "by_source_root"
, I would expect this not to be ambiguous, but the one in
helloworld/translator/BUILD
to be used. However, when I run
pants --no-local-cache peek helloworld/translator/translator.py
, I get an unresolvable ambiguity:
Copy code
09:29:59.13 [WARN] The target helloworld/translator/translator.py:lib imports `rich`, but Pants cannot safely infer a dependency because more than one target owns this module, so it is ambiguous which to use: ['helloworld/greet:greet', 'helloworld/translator:translator'].

Please explicitly include the dependency you want in the `dependencies` field of helloworld/translator/translator.py:lib, or ignore the ones you do not want by prefixing with `!` or `!!` so that one or no targets are left.

Alternatively, you can remove the ambiguity by deleting/changing some of the targets so that only 1 target owns this module. Refer to <https://www.pantsbuild.org/2.26/docs/using-pants/troubleshooting-common-issues#import-errors-and-missing-dependencies>.
09:29:59.13 [WARN] Pants cannot infer owners for the following imports in the target helloworld/translator/translator.py:lib:

  * rich (line: 9)

If you do not expect an import to be inferable, add `# pants: no-infer-dep` to the import line. Otherwise, see <https://www.pantsbuild.org/2.26/docs/using-pants/troubleshooting-common-issues#import-errors-and-missing-dependencies> for common problems.
[
  {
    "address": "helloworld/translator/translator.py:lib",
    "target_type": "python_source",
    "dependencies": [],
    "dependencies_raw": null,
    "description": null,
    "goals": [
      "run"
    ],
    "interpreter_constraints": null,
    "resolve": null,
    "restartable": false,
    "run_goal_use_sandbox": null,
    "skip_black": false,
    "skip_docformatter": false,
    "skip_flake8": false,
    "skip_isort": false,
    "skip_mypy": false,
    "source_raw": "translator.py",
    "sources": [
      "helloworld/translator/translator.py"
    ],
    "sources_fingerprint": "e71e261f5a1f4adbc68b626ad12c6e1de9376ac9945e204b1041388f6a52c705",
    "tags": null
  }
]
Pants version
2.26.0
OS Linux Additional info I have a suspicion this bug is due to
os.path.commonpath
as used here. This function, because of the missing training slash, has
Copy code
assert os.path.commonpath(
    ["helloworld/translator/translator.py", "helloworld/greet:greet'"]
) == "helloworld"
assert os.path.commonpath(
    ["helloworld/translator/translator.py", "helloworld/translator:translator'"]
) == "helloworld"
If there were a trailing slash, then it would be able to see a difference:
Copy code
assert os.path.commonpath(
    ["helloworld/translator/translator.py", "helloworld/translator/:translator'"]
) == "helloworld/translator"
assert os.path.commonpath(
    ["helloworld/translator/translator.py", "helloworld/greet/:greet'"]
) == "helloworld"
pantsbuild/pants