Repository navigation
Expose language, locale, and timezone info #167
Description
It would be good for WASI to be able to expose the information needed to implement the POSIX LANG, LC_*, and TZ environment variables.
One option would be to literally forward these environment variables through WASI's environment-variable system, however we'll likely want this information in programs which don't otherwise use environment variables, so we should consider a different API -- WASI libc could translate it into the environment variables for compatibility if needed.
Activity
sbc100 commentedon Dec 3, 2019
Are you saying you are worried about adding the cost of
getenv+__environto programs that just need the to know the timezone?Seems unfortunate given that we have the mechanism in place already to use environment variables.
But I guess size in important?
If there are enough features that use environment variables like then then cost of having an environment at all will at least be amortized, and the more new APIs we design to replace erstwhile environment variables the less we benefit from the amortization.
sunfishcode commentedon Dec 4, 2019
Environment variables in general aren't a great fit for shared-nothing linking.
Applications don't have any way of indicating up front which environment variables they need, so we tend to implicitly pass more than is needed, which needlessly leaks information.
Also, environment variables are limited to strings, so they aren't typed. They tend to get used to pass around path strings, which also makes them tend to implicitly depend on a shared filesystem view, which we can support with compatibility mechanisms, but it weakens the "shared-nothing" part of shared-nothing linking.
We can continue to support environment variables for compatibility with existing code, but it's worth thinking about whether we can avoid having essential functionality depend on environment variables in general, so that embeddings and applications which wish to avoid using environment variables altogether can do so without missing out.
sbc100 commentedon Dec 4, 2019
OK so our stance is generally "We don't like environment variables in WASI for a number of reasons".
So we will avoid them within WASI itself, but allow users to use them for legacy purposes if they wish?
I think that makes sense. We might want to document that somewhere.
sunfishcode commentedon Jan 10, 2020
#192 briefly mentions this stance on environment variables.
complexspaces commentedon Apr 4, 2023
👋 Hey there, has there been any further thinking on support for this feature? It recently came up on 1Password/sys-locale#18 where we had to hardcode
Nonein the locale fetching implementation for thewasitarget family for the time being.