Repository: pantsbuild/pants

Issue:
Imports from packages specified in `[mypy].extra_type_stubs` are flagged as "unowned"
**Describe the bug**

In `pants.toml`, we have:
```toml
[python-infer]
unowned_dependency_behavior = "warning"

[mypy]
extra_type_stubs = [
    "boto3-stubs[config,ec2,ecr,lambda,route53,sagemaker,sagemaker-runtime,s3,ssm,sts,sqs]==1.21.23.post1",
]
```

Then in a source file we have:
```python
if TYPE_CHECKING:
    from mypy_boto3_ec2 import EC2Client, EC2ServiceResource
else:
    EC2Client = object
    EC2ServiceResource = object
```

The line that imports from `mypy_boto3_ec2` is flagged as having an "unowned" dependency.

**Pants version**

2.13.0 and 2.14.0rc0

**OS**

Both

**Additional info**

This problem has been lurking for awhile but I only found it while testing out an upgrade to Pants 2.14, which made "warning" the default value of `[python-infer].unowned_dependency_behavior`.


Discussion:
I'm not sure what the correct behavior here would be. Reminder that you can instead specify those stubs as normal `python_requirement` targets.

In the meantime, a workaround is to add `# pants: no-infer-dep` to the line
Yeah, I'm pushing to get us off of `extra_type_stubs` entirely. If the existing behavior is intended then I'd say there is a docs "bug" - it'd be nice to call out the limitation in this section: https://www.pantsbuild.org/docs/python-check-goal#third-party-type-stubs
I think my expectation was that typically you have both stubs and a "normal" `python_requirement` for the actual implementation, e.g. `requests` in `python_requirement` and `types-requests` in `[mypy].extra_type_stubs`. So the import will be "owned" by that core `python_requirement`, and no issue.

Here, do you have a `mypy_boto3_ec2` `python_requirement`?
> Here, do you have a `mypy_boto3_ec2` python_requirement?

We don't, because it's an unfortunately-named stubs-only package for a subset of `boto3`. We're still running our pre-Pants build setup in parallel and didn't want to bloat its venv with even more stuff when we were first rolling out `mypy`, so `extra_type_stubs` seemed like an easy way to keep things separate. We've since figured out other ways of keeping dependencies separated but never went back to clean up our hackery 😂
Okay so I'd say this is probably a docs bug. It would be good to fix the actual code, but that's going to be hard to pull off, including requiring a new plugin hook because `pants.backend.python` does not "know" `pants.backend.python.typecheck.mypy` exists. Given how low frequency I suspect this to be thanks to normally having a `python_requirement`, I think it's not worth that complexity. Wdyt?

Any interest in submitting a docs patch?
@Eric-Arellano yeah you can assign this one to me (not sure when I'll get to it, but I'll add it to the list)

Resolving patch:
diff --git a/src/python/pants/backend/python/typecheck/mypy/subsystem.py b/src/python/pants/backend/python/typecheck/mypy/subsystem.py
--- a/src/python/pants/backend/python/typecheck/mypy/subsystem.py
+++ b/src/python/pants/backend/python/typecheck/mypy/subsystem.py
@@ -156,7 +156,7 @@ class MyPy(PythonToolBase):
     extra_type_stubs = StrListOption(
         advanced=True,
         help=softwrap(
-            """
+            f"""
             Extra type stub requirements to install when running MyPy.
 
             Normally, type stubs can be installed as typical requirements, such as putting
@@ -164,6 +164,10 @@ class MyPy(PythonToolBase):
             Alternatively, you can use this option so that the dependencies are solely
             used when running MyPy and are not runtime dependencies.
 
+            NOTE: Dependencies specified in this way are not visible to dependency inference,
+            and cannot be referenced as explicit dependencies. See {doc_url('python-check-goal')}
+            for more information about problems this can cause, and how to work around them.
+
             Expects a list of pip-style requirement strings, like
             `['types-requests==2.25.9']`.
 


Test patch: