Unfortunately if I now get:

16:45:19.88 [WARN] Ignoring `[python_setup].resolve_all_constraints` option because constraints file does not cover all requirements.

which I think means my

constraints.txt

is being ignored (I didn't quite grok the docs). That seems unfortunate. Note that the stubs are

git+http

style so I can't freeze them even if I did put them in the

<http://requirements.in|requirements.in>

. Is there no way to get these 3rd party type stubs but also keep the

constraints.txt

working?

Try 2.5.0rc0 if you're on 2.4. I think https://github.com/pantsbuild/pants/pull/11907 is mean to handle this case

Thanks @hundreds-father-404. So putting this all together I think if we move to 2.5.0rc0 we can put the

git+https

requirements in our

<http://requirements.in|requirements.in>

but we'd still need to add an explicit dependency on any type stubs on any targets that use `numpy`; that part can't be made automatic. Is that correct?

Oh that's an interesting idea! Right now, we have special cased code so that we are fine with ambiguity when the type stub is first-party, like a

.pyi

file checked into your repo. I like the idea of allowing that for 3rd party code too Would you mind opening a GitHub issue with this idea please? https://github.com/pantsbuild/pants/issues

like a

.pyi

file checked into your repo

Which btw, you could use this as a workaround for now

Thank you! Would you have an interest in implementing this? If so, I'm happy to write some detailed instructions on how to go about it

I'm afraid I don't have time at the moment, but some other time.

@plain-carpet-73994 I'm starting work on this as a fun side project. One thing that would help me a lot if you have a few minutes to spare...research what are some common type stub libraries out there so that we can define a default

stubs_mapping

. For example,

{"numpy-stubs": ["numpy"]}

That's great to hear! Not sure if a default makes sense. For example, there's more than 1 numpy type hinting library that I found. I think the really common stubs are already in typeshed so this would only be for less common libraries. For those I'm not sure there's much of a convention. Though I haven't had a reason to look for a lot of stubs until now. If I do detect a pattern I'll let you know.

fyi @plain-carpet-73994 https://pantsbuild.slack.com/archives/C0D7TNJHL/p1623217337054700