-
-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
extra_env_vars field for system_binary #20374
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice so far! See my one comment about the proposed semantics (the "fingerprinting" is more of a detail than most users will understand or care about).
As for testing - should be easy to test by running the system binary env
with some contrived env var and checking that the value shows up in its output!
help = help_text( | ||
""" | ||
Additional environment variables to provide to the system binary during fingerprinting. | ||
This has no effect on the execution of the binary in the scope of an `adhoc_tool` or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think these env vars should always be set, not just for fingerprinting (although the ad-hoc tool values should override them if specified). In your case it would mean you could set DISPLAY in just one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback. Need clarification.
- Let's assume an
adhoc_tool
has multiplerunnable_dependencies
. One of them setsextra_env_vars
in thesystem_binary
. That means theadhoc_tool
invocation would set the vars for the whole invocation, means for therunnable
and all other binaries. Is this a safe assumption? - If yes, I would combine all
extra_env_vars
of allrunnable_dependencies
. This may also conflict, e.g. one sets an env var to take it over from pants env, the other binary defines it explicitly. How to deal with this? - If, however, the
adhoc_tool
definesextra_env_vars
I would only consider this field. - Is
shell_command
also affected?
I think it comes down to what we think the user wants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that again and I think you're right.
If a variable is needed for fingerprinting, it most certainly is also needed for running the tool. So I will merge all env var requests of binaries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think merge them in order of specificity, so the more specific targets overrides the less specific one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this documentation needs updating.
I implemented the
|
This is what I meant by order of specificity, yes.
I don't think so, you likely want to override on purpose.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! See comments inline.
Going to add @chrisjrn to the reviewers, since he has a better handle on the env vars stuff here than I do
@@ -87,6 +92,9 @@ async def _find_binary( | |||
env.update(**(rds.extra_env or {})) | |||
append_only_caches = rds.append_only_caches | |||
immutable_input_digests = rds.immutable_input_digests | |||
if extra_env_vars: | |||
extra_env = await Get(EnvironmentVars, EnvironmentVarsRequest(extra_env_vars)) | |||
env.update(extra_env) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could stomp the PATH or _PANTS_SHIM_ROOT, no? Seems like the update order should be reversed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reversed the order
help = help_text( | ||
""" | ||
Additional environment variables to provide to the system binary during fingerprinting. | ||
This has no effect on the execution of the binary in the scope of an `adhoc_tool` or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this documentation needs updating.
@@ -266,14 +277,16 @@ async def _resolve_runnable_dependencies( | |||
shim_digest_path = f"_runnable_dependency_shims_{shim_digest.fingerprint}" | |||
immutable_input_digests = {shim_digest_path: shim_digest} | |||
_safe_update(immutable_input_digests, merged_extras.immutable_input_digests) | |||
environment = {"_PANTS_SHIM_ROOT": "{chroot}"} | |||
environment.update(runnable_extra_env_vars) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should switch the update order here, we never want to stomp _PANTS_SHIM_ROOT (although it's highly unlikely)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reversed the order
I addressed the comments. Unfortunately I feel a bit lost on the implementation of the overall feature.
then running it as Any advice? |
Hmm, I'll dive a little deeper but I would like to hear from @chrisjrn , who has the most context here. |
I'm a bit rusty on this code and would gladly do a pairing session (ask me on Slack!), but my recollection is that the |
80f3d41
to
db8ef72
Compare
Heya, just checking in. What's the status of this PR? Is it ready for a re-review or is it waiting on something else? |
What works:
Pending issues:
Last time I worked on the PR I felt a little lost with the code base and went out of time. |
Fixes #20373