Add unstable env::set and env::remove by LunaBorowska · Pull Request #92431 · rust-lang/rust (original) (raw)

The libs-api team discussed this at last weeks' meeting. There were a couple concerns with this PR as-is:

• We want to push for migration to future-proof safe alternative APIs, which don't modify the environment (these need to be designed and implemented)
  • In particular, a migration to the unsafe functions makes a subsequent migration to the safe alternative APIs less likely.
• We want to avoid using up these names (which are relatively nice) just to provide equivalent (but unsafe) APIs
  • In the future, a Rust-only environment or other alternatives to the env modification/reading design space may open up, and in those cases we may want these names.

To that effect, the next steps in this space are (roughly):

• Set of PRs for key rust-lang maintained APIs which currently are controllable only via the environment (RUST_BACKTRACE in std, RUST_LOG in log, potentially a few others)
• Once these land, blog.rust-lang.org post which asks library authors to work on their own libraries and provide alternative APIs to set configuration. Point at how std's APIs were designed/modified as a case study for a good approach. (in particular, most cases will want to keep the option to set environment variables, but also provide an alternative API for programmatic access).
• Mark set_var/remove_var (at least) as unsafe, likely with a custom #[rustc_safe_deprecated] or so attribute which allows us to reuse the same names and eases migration.
  • At this time, we'll want to consider the "risk" of users using these APIs within existing unsafe blocks (and so not knowing about the new obligation), but that seems relatively unlikely to me. Crater may provide some partial data here.
• Some time later, likely several years, examine whether we can provide safe APIs (e.g., because libc's and similar have added new APIs we can rely on).

Would you be interested in helping to drive the first step here? I believe there may already be some design discussions (or PRs) open. Otherwise, I plan to invest in the coming week(s) in pushing this plan forward.