#17343 Synthetic targets for lockfiles break when a target has the same name as the resolve Issue created by Eric-Arellano To reproduce, apply this diff:

diff --git a/3rdparty/python/BUILD b/3rdparty/python/BUILD
index 9803dba972..764a4a09e2 100644
--- a/3rdparty/python/BUILD
+++ b/3rdparty/python/BUILD
@@ -2,13 +2,14 @@
 # Licensed under the Apache License, Version 2.0 (see LICENSE).
 
 python_requirements(
+    name="python-default",
     module_mapping={
         "strawberry-graphql": ["strawberry"],
         "beautifulsoup4": ["bs4"],
         "python-gnupg": ["gnupg"],
     },
     overrides={
-        "humbug": {"dependencies": ["#setuptools"]},
+        "humbug": {"dependencies": ["python-default#setuptools"]},
     },
 )

Then run `./pants dependencies 3rdparty/python:python-default#setuptools`:

ValueError: The explicit dependency `3rdparty/python/user_reqs.lock:python-default` of the target at `3rdparty/python:python-default#setuptools` does not provide enough address parameters to identify which parametrization of the dependency target should be used.
Target `3rdparty/python:python-default` can be addressed as:
  * 3rdparty/python:python-default
  * 3rdparty/python:python-default#PyYAML
  * 3rdparty/python:python-default#ansicolors

I'm not sure what the correct solution is here. Maybe we should add something special to the synthetic target like

:python-default--resolve

to reduce the risk of collisions? This is not hypothetical - it broke Toolchain when upgrading to 2.15. -- It would also probably be useful to add an option to disable synthetic targets. Right now, the only escape hatch was to rename Toolchain's target. -- cc @kaos - thoughts? pantsbuild/pants

#17343 Synthetic targets for lockfiles break when a target has the same name as the resolve Issue closed as completed by kaos pantsbuild/pants