https://pantsbuild.org/ logo
Join Slack
Powered by
Seeing something wild: I run mypy via `pants check...
# development
h
Seeing something wild: I run mypy via 
pants check
and it runs (but fails on some check errors), i.e., the mypy.pex has been created and cached. But then a subsequent run tries to rebuild the mypy.pex from the lockfile and that fails with a wheel building error.
🤦‍♂️ 1
Namely
Copy code
pip:       /Users/benjyw/.pyenv/versions/3.11.9/include/python3.11/Python.h:23:12: fatal error: 'stdlib.h' file not found
pip:       #  include <stdlib.h>
pip:                  ^~~~~~~~~~
pip:       1 error generated.
Sometimes rerunning succeeds, or if not I can force the issue by nuking 
~/.cache/pants
I don't understand this at all
Oh, and in some cases I can also subsequently cause this:
Copy code
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
native_engine.IntrinsicError: materialize_directory() request to sandboxer process failed: status: FailedPrecondition, message: "Could not walk unknown directory at : Was not present in the local store: Digest { hash: Fingerprint<ace0a93140dafd5d0aa852174778d1895dbaebb0eea474fbf7b7a894cb57e266>, size_bytes: 497 }", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Fri, 12 Dec 2025 03:22:59 GMT", "content-length": "0"} }
So this might be an lmdb_store issue
Or that might be a red herring due to the sandboxer having state pulled out from under it
w
Interesting, is it possible that pyenv isn't always reliably picked up?
e.g. the mypys swap between system and pyenv?
c
I have noticed -- but never run down -- where 
check
seems to populate some things in 
~/.pex
(escaping the sandbox?) instead of sticking to named_caches
h
I'm going to get to the bottom of this so help me god
At least I have a reliable repro now
This happens even with sandboxer turned off, so it's not that.
I don't think this is directly related, but now that I'm diving into debug output I am noticing way more invalidation than I'd expect, due to 
SessionValues
changing (due to the run_id changing, and potentially env vars). But that is for another day.
Hmm, maybe it is related. The second run schedules the "Building 17 requirements for requirements.pex" process, then cancels it, then schedules it again, then cancels it again, then the third run fails
w
Its not updating anything in the workspace, is it?
h
Don't think so, I think it's due to differences in the CompleteEnv
Yep, I think that's it
The process that succeeds has 
CPPFLAGS
and the like set correctly
The one that fails has 
CPPFLAGS='' LDFLAGS='' PATH=''
and more
so those have fallen out of the env for some reason
w
oof
h
Oh, I am an idiot, I know why
It's due to a change I made that rippled further than I thought
OK, nothing to see here...
3 Views
Open in Slack
PreviousNext
Powered by