Issues using mypy plugin for protobuf when using remote execution. #11742
Assignees
Labels
Comments
|
@charlesoconor I'm guessing you have a The path that can't be found has 2 hashes amongst its components. The 1st is the PEX file hash - which is constant. The second is a hash of variables that can affect interpreter selection for that PEX file: The script in question is here and line 13 is the last line: pants/src/python/pants/backend/python/util_rules/pex.py Lines 688 to 704 in e4a00eb You can see above, the path that's turning up not found is checked for existence and re-generated in an if block above. The re-generation though must have a different PEX_PYTHON_PATH from when the script was generated: Looking into this made me realize there is a bug in that Pex code. It should be hashing the contents of PATH too since that also influences interpreter selection: pex-tool/pex#1282. That bug is not in play here. |
|
Also seeing this issue in reapis-testing https://gitlab.com/remote-apis-testing/remote-apis-testing/-/merge_requests/231 for |
|
Excellent - that's super helpful to know and narrows the bug search space. Thanks @tom--pollard. |
stuhood
changed the title
|
Alright - https://gitlab.com/remote-apis-testing/remote-apis-testing/-/blob/master/docker-compose/run.sh was invaluable here. With: $ git diff
diff --git a/matrix.yml b/matrix.yml
index e8ece49..0aa8829 100644
--- a/matrix.yml
+++ b/matrix.yml
@@ -82,7 +82,7 @@ projects:
filename: docker-compose-pants.jinja2_template
version_refs:
PANTS_COMMIT:
- value: 5e76f94ccabddac74b622dbb9087fc7fd2d8ba17
+ value: 37d7d99a66d28f05be1e84b41871a3a9f806de0c
update_function: get_latest_commit_hash_from_git_repo
update_args:
repo: https://github.com/pantsbuild/example-python.gitThe failure is: Looking at the worker cache, the shim script has: So, the failure shows an expected |
|
The issue is over here: #11040 (comment) Shouldn't be too bad to fix. |
|
I broke out #11753 with the targeted fix. The simple rule here is we can never store files in the CAS that contain absolute paths - which was already known. The corollary is we should never be setting environment variables for processes that likewise contain absolute paths, except maybe |
|
The cherry pick of the needed fixes to get 2.3.x working with remote execution is in #11765. |
jsirois
added a commit
that referenced
this issue
Mar 21, 2021
Previously we cheated and exported PEX_ROOT as the absolute path of the named caches dir + "pex_root". Since we obtained the absolute path from the local machine, this cheat was unmasked by remote execution where the absolute path of the named caches dir was different. Now we use a relative PEX_ROOT that ties in with append_only_caches. The VenvPex scripts are updated to use relative paths as well. Fixes #11753 Fixes #11742 (cherry picked from commit 4210c6c) ___ And in support of the above: Simplify Black file specification. (#11762) Black supports passing an explicit list of files and we have that. This clears the way for having the pex_root named cache symlinked into the Black Process chroot without having Black trying to recursively format everything in there. (cherry picked from commit c927cee)
|
This fix will go out in the 2.3.1 series. |
|
@charlesoconor the fix is now available in 2.3.1rc0: https://pypi.org/project/pantsbuild.pants/2.3.1rc0/ |
|
Thanks @jsirois! |
|
Thank you! |
|
@charlesoconor if you get a chance to try out 2.3.1rc0 and report back, that would be great. Although we have confirmation of a fix via the remote-apis-testing project, confirmation your issue is fixed would be good to have prior to cutting 2.3.1 final. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looks like
bin/protoc-gen-mypyisn't being copied over. Everything works well whenI'm using pants
2.3.0rc3but I believe I had the same issue with2.2.0I'm using build barn for doing remote execution.
The feature works correctly without running remotely.
The text was updated successfully, but these errors were encountered: