Re <https://pantsbuild.slack.com/archives/C046T6T9...
# development
b
Re https://pantsbuild.slack.com/archives/C046T6T9U/p1645750979476569?thread_ts=1645750208.194249&amp;cid=C046T6T9U If there's valid reason to violate the official deprecation policy, and it seems there is here, then imo that's reason to revise the policy a bit rather than just violate it seemingly arbitrarily. That the current policy may have led to persisting a "super confusing" situation for a while suggests to me that something is worthy of a bit of revision here. Thoughts...?
1
e
In this case though couldn't the env vars be deprecated and during the deprecation cycle just be merged with the blessed env var subsystem, potentially erroring if there is a conflict on merge to keep the deprecation promise; i.e.: not trample the deprecated env vars?
h
Yeah, it is certainly theoretically possible to get the deprecation working. I couldn't figure it out though and I exceeded my timebox. Maybe I could get it with fresh eyes