-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add the ability to see inherited envs on Command #110327
Add the ability to see inherited envs on Command #110327
Conversation
r? @thomcc (rustbot has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #110331) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
0a3a825
to
98c5aaa
Compare
This comment has been minimized.
This comment has been minimized.
98c5aaa
to
e841217
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #114590) made this pull request unmergeable. Please resolve the merge conflicts. |
This is a reference implementation for one of the solution "sketches" in rust-lang/libs-team#194. ## Problem statement(s) - Problem 1: Cannot observe effects of `Command::env_clear` - Problem 2: The "capture" logic has no exposed single source of truth Problem 1 is a capability problem (I can't work around this). Problem 2 is a usability and stability problem. ### Problem 1: Cannot observe effects of `Command::env_clear` As documented in [my merged PR](#109272), calling `env_clear` will cause the "capture" logic to skip inheriting from the parent process. While a developer can set this value, they cannot programmatically observe if it has been set (though they can manually observe it via "alternative" debug formatting `{:#?}`). The end goals of programmatically observing that effect is listed below in "Motivation". This problem prevents me from reproducing the capture logic in a library where I cannot observe if `env_clear` has been called. Even if this problem is solved, a related problem is detailed below. ### Problem 2: The "capture" logic has no exposed single source of truth Even if we could directly observe the effects of calling `env_clear`, every developer who needed this information would need to reproduce this "capture" logic https://github.com/rust-lang/rust/blob/3a5c8e91f094bb1cb1346651fe3512f0b603d826/library/std/src/sys_common/process.rs#L36-L51 and hope that it does not change or that their implementation does not diverge. If the outcome of this logic is exposed, then it will: - Solve problem 1 - Prevent divergent reimplementation of "capture" logic ### [sketch] Expose captured env logic via a new `capture_envs` method on `Command` We could add a method that exposes that information directly: ```rust let command = Command::new("ls"); let envs: HashMap<OsString, OsString> = command.capture_envs().collect(); ``` The name `capture` matches internal naming concepts and helps to reinforce that the value method will return a point in time value. This sketch would solve problems 1 and 2. I'm open to name suggestions.
9f35c5b
to
a2776c1
Compare
This comment has been minimized.
This comment has been minimized.
a2776c1
to
c9e8d86
Compare
This comment has been minimized.
This comment has been minimized.
c9e8d86
to
4266fea
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #117285) made this pull request unmergeable. Please resolve the merge conflicts. |
Add the ability to see inherited envs on Command
This is a reference implementation for one of the solution "sketches" in rust-lang/libs-team#194.
Problem statement(s)
Command::env_clear
Problem 1 is a capability problem (I can't work around this). Problem 2 is a usability and stability problem.
Problem 1: Cannot observe effects of
Command::env_clear
As documented in my merged PR, calling
env_clear
will cause the "capture" logic to skip inheriting from the parent process. While a developer can set this value, they cannot programmatically observe if it has been set (though they can manually observe it via "alternative" debug formatting{:#?}
).The end goals of programmatically observing that effect is listed below in "Motivation".
This problem prevents me from reproducing the capture logic in a library where I cannot observe if
env_clear
has been called. Even if this problem is solved, a related problem is detailed below.Problem 2: The "capture" logic has no exposed single source of truth
Even if we could directly observe the effects of calling
env_clear
, every developer who needed this information would need to reproduce this "capture" logicrust/library/std/src/sys_common/process.rs
Lines 36 to 51 in 3a5c8e9
If the outcome of this logic is exposed, then it will:
[sketch] Expose captured env logic via a new
capture_envs
method onCommand
We could add a method that exposes that information directly:
The name
capture
matches internal naming concepts and helps to reinforce that the value method will return a point in time value.This sketch would solve problems 1 and 2. I'm open to name suggestions.