The PR to stabilize --env-set has been closed 2 years ago with no real explanation: Stabilize `--env-set` option by GuillaumeGomez · Pull Request #119926 · rust-lang/rust · GitHub.
That feature is still very much needed for build systems that cannot easily set environment variables when invoking compiler command (anything using Ninja, like Meson).
What's missing to make it move forward?
I’m not at all familiar with this feature, but from skimming the comments on the PR, it seems that what is needed is:
A more thorough stabilization report; this would include such things as descriptions of successfully using the unstable feature in third-party build systems. (The thing being defended against here is stabilizing something that doesn’t actually help users because it was incorrectly designed; the stabilization report should be the evidence that the feature actually works for this purpose.)
This report would be part of opening a new stabilization PR.
A resolution of the concern about how this option interacts with the compiler reading environment variables itself — that would constitute both documenting what such behaviors are, and changing it if it is currently bad.
This will involve either behavior changes (to improve the interaction) or documentation changes (to document what the interaction is). This should probably be a separate PR prior to the stabilization PR.
Thanks for your reply.
It has been successfully used in Meson, see Stabilize `--env-set` option by GuillaumeGomez · Pull Request #119926 · rust-lang/rust · GitHub. It's waiting for the feature to be stabilized in rustc for before merging, and surely needs a big rebased since it's 2 years old. But I think that validates the concept.
About the compiler reading environment variables itself, I believe that's unrelated and --env-set should not affect that, but I'm not a Rust dev so I cannot really judge. I commented on the PR as well.
The reason I list the things I do is because the most effective way to get something stabilized is to figure out what will address the concerns, and send PRs as needed.
Then the thing that needs doing is to update the documentation, and the implementation if needed, so that that is in fact what --env-set does, and is documented as doing.
Do you know who can approve the stabilization if those 2 concerns are solved (maybe you?). The author wants to be sure he's not wasting his time before proceeding: Stabilize `--env-set` option by GuillaumeGomez · Pull Request #119926 · rust-lang/rust · GitHub.
I am not a member of T-compiler or any Rust Project team and cannot merge any PRs. I am only providing suggestions for what you can do based on general principles.
You wrote in the PR thread:
- Should --env-set affect other usages of environment. IMHO, no, and it's already well documented that only those 3 functions are affected:
I think this is not really true. The documentation says what it does affect, but
If a PR which adds that clarification to the documentation were merged, presumably that would resolve the concern.
Fair enough, thanks!
Just for future reference, commenting on an old closed PR is likely to be overlooked by most people, except perhaps the PR author (who likely doesn't have permission to approve stabilisation themselves). It's usually better to comment on the tracking issue if you want relevant teams to see it.
That's exactly why I opened this discussion here. I wanted to open a github issue but it redirected here for feature discussions. If there is a better place to bring visibility, please let me know 