https://pantsbuild.org/ logo
Join Slack
Powered by
I only found one mention of it in the github issue...
# general
h
I only found one mention of it in the github issues, but has there been any traction behind using 
pyright
for type checking instead of 
mypy
? I'm finding 
mypy
incredibly prohibitive to get working. For a tool written to work with python as the intended target, they're rather inflexible. Pyright has been working great for us, but it's another thing that requires us to construct a large venv at the moment and type check every file all the time.
👍 1
h
There hasn't been, but I imagine it wouldn't be too hard to add, at least initially by cargo-culting the mypy rules.
Is that something you'd like to take a stab at? We can assist
h
Yeah, I think this would be an effort I'd be interested in supporting. Feeling pretty passionately about now that mypy has thwarted my attempts to get started with an integration for the third time.
h
I don't know much about 
pyright
but I'm vaguely assuming it's similar to mypy in spirit?
h
I'm not too familiar with it to be able to call out the important details about how they differ. In usage they are very similar.
It seems pyright relies on having a venv more directly than what I see out of mypy.
b
One big difference is pyright is written in typescript and requires npm to run.
👀 1
h
Well, we were going to have to start dealing with the JS landscape sooner or later...
h
I guess I was hopeful since it's still a console script which seems like Pants handles running happily.
I've done some quick browsing to start getting acquainted, but it would probably be useful to get a rundown of how the mypy integration works at a high level if it's not too much trouble. Also doesn't need to be high priority. Faster linting was one of the things on our migration plan, but there's a lot of other stuff we can tackle. Getting 
pants test
almost fully integrated has already made our build system happier!
❤️ 1
h
Getting pants test almost fully integrated has already made our build system happier!
Glad to hear! How so?
but it would probably be useful to get a rundown of how the mypy integration works at a high level
Essentially: 1. Determine which files/targets to run. MyPy needs transitive dependencies. We also do some fancy partitioning to handle multiple "resolves" (lockfiles) in the repo, along with multiple conflicting interpreter constraints like Py2 vs Py3 2. Build the MyPy PEX, along with an extra PEX if 
[mypy].extra_type_stubs
is set. Separately, build a PEX for user requirements using 
pex_from_targets.py
3. Locate config files and set up the argv. Also we figure out what 
python_version
to use if you didn't already set it. Figure out MYPY_PATH and PYTHONPATH values 4. Use 
--pex-path
to merge all those PEXes from step 2 and invoke with inputs from step 3.
h
All our unit tests were with 
pytest
and, despite parallelization, the build took around 4 to 5 minutes. With 
pants test
we're hitting at most around 40 seconds test time regularly and only use 
pytest
for the things we weren't able to migrate at this time (because of the way they're written).
🙌 1
h
That's amazing! That's with warm or cold cache?
h
Warm cache. I would expect no cache would probably be similar or longer to running 
pytest
like we were. We got remote cache set up really easily with our already existing 
bazel-remote
deployments so that's been an extra benefit.
🙌 1
When local caches are hit, it's around 20 seconds. The remote cache hits were what bumped up the time a little bit.
h
That makes sense, sweet! Would you be willing to let us quote this on Twitter and/or the testimonials page https://www.pantsbuild.org/docs/testimonials? Helps us to get out the word
h
I'll check in on it
👍 1
Open in Slack
PreviousNext
Powered by