#12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): It's maybe worth pointing out that `setEnv` has been introduced with base-4.7.0.0 (via #7427 & https://mail.haskell.org/pipermail/libraries/2012-October/018560.html) Replying to [comment:1 bergmark]:
I think it's important to make sure that there is some kind of mention/warning to let users know that their code changed because of this.
On the one hand, we use semantic versioning to signal this very kind of semantic API changes; on the other hand, `base` makes inflationary use of major version increments due to its large API surface, so that we end up with a sub-optimal signal/noise ratio, resulting in API consumers not paying attention anymore... :-(
I see three ways to accomplish this:
* Deprecate `setEnv` and add the new function under a new name
I think that'd be the safest approach given the circumstances, and it would side-step all the BC issues; the only downside is having to figure out a good name for the new function... :-)
* Add a warning pragma for one release cycle and then make the change
That's still gonna result in silent failures for users which don't pay attention to semantic version signalling nor compile warnings or which happen to skip that one release cycle which warned about it.
* Change the parameter to only accept non-empty strings
how?
What about staying compatible with several versions of base? Should users never use an empty string (effectively banning the use of empty env vars), and/or should we refer users to the base-compat package?
In hindsight, maybe we should have thrown an exception for situations where `setEnv` would act like `unsetEnv`, or unify `setEnv` with `unsetEnv` by using `:: String -> Maybe String -> IO ()`... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12494#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler