I'm adding typechecking with mypy to our project, and have hit a bit of a snag. I suspect it's due to Pants' implementation, but I'm not an mypy expert by any stretch. Basically, we've got a monorepo with several Python apps and libraries. Everything but one library was typed by mypy in our pre-Pants repository; that one library was instead typed by Pytype because it's got some peculiarities that are better served by being analyzed by Pytype. Ideally, I'd like to just run mypy via Pants over everything but that one library. However, it looks like Pants supplies the files of the targeted apps and libraries, as well as their local dependencies, directly to mypy. This results in our pytype-typed library being fed into mypy for analysis, and then failing the run as a result. This seems to happen no matter what kind of filtering I provide. Is there any way of performing this kind of flitering? Thanks in advance!

Indeed. We could change it so that we don't say in the argv all the deps too. When I added MyPy, iirc, it behaved the same way either way, so we went with specifying every file under the thinking that it would improve the rate of cache hits But if you can show that that is not the case, that leaving off a dep from the argv does change things, then we can very easily fix this! So, my ask: could you please experiment with this and report back? No need to use Pants in your experiment, only a simple example repro

yeah, I'll see what I can cook up

Thanks! Also note that transitive deps will still always be in the chroot and I don't think we can change that

I think them being present should be OK. I think the key bit is whether they're passed directly to mypy for analysis

To confirm, you are saying that the change in behavior is purely based on the arguments that you pass to MyPy?

mypy project/app.py project/dep.py

vs.

mypy project/app.py

? not based on whether the file is present in the chroot?

I believe so, yes. I may need to do some additional poking around in the morning, but I was not manipulating any files on disk; it was purely through manipulating arguments to mypy.

Yes! use

--no-process-execution-cleanup-local-dirs

. There will be something like

mypy.pex

in it, and the chroot of all the relevant files. You can then do

./mypy.pex arg1 arg2

Cool! So, I did that and discovered that I'd need to modify the

__run.sh

file and/or the

__files.txt

file. When I ran

__run.sh

pointed to a version of

__files.txt

that I had removed my pytest-only library files from, I get the behavior I'm after. I didn't change any of the files that were in the chroot. So, I think that is fairly strong support for this theory 😄

Excellent! Would you be interested in putting up a PR to fix this? I can type up some instructions if so

(trying to run

mypy.pex

directly failed because I didn't have the environment present in __run.sh)

Hope this helps! Let me know if you have questions! https://github.com/pantsbuild/pants/issues/11553 Check out https://www.pantsbuild.org/docs/contributor-overview for a guide on making contributions, including how to get set up. It would also be fruitful to read over https://www.pantsbuild.org/docs/plugins-overview and the Target API and Rules API overviews. It's okay if things don't make perfect sense, you should be able to monkey see, monkey do for most of this

This is great @hundreds-father-404... thanks very much!

Hey @brash-baker-91190, checking if you're still interested in working on #11553? I can try to fit it in today or next week if not

I am still interested... I got the code working, but not the tests, then got sidetracked with some life stuff, then some code on the master branch changed and I have yet to get the resulting conflicts with my code resolved 😕 I hope to be able to get back to it soon, but I don't want to hold up anything.

Okay sounds good, thanks for the update! I hear you there with that all, same happens to me 🤷‍♂️ And no worries, I don't think anyone is being held up

cool, thanks... hopefully I'll have some time this weekend to get back to it 🤞