Should CLI tool wrapper scripts enforce locale env variables expected by Elixir?

[michaelklishin]

See #1572 and elixir-lang/elixir#3548.

TL;DR: Elixir unconditionally emits a warning (as of elixir-lang/elixir@3ec0d20) when running in an environment where locale variables are set to a non-UTF-8 value. The warning can trip up tools such as Puppet that parse CLI tool output (we will not debate whether that's a good idea here).

While I don't buy into the argument that

Forcing the env to a specific locale seems a bit drastic

we can easily force it in a way that Elixir requires in our wrapper scripts.

@dumbbell @hairyhum I recall we had this discussion before but the conclusion was never explicitly stated publicly.

Should we force locale/language variables for CLI tool invocations or does the potential downsides outweigh the gains for provisioning tools that have to parse CLI output?

Since we don't localise CLI tool output, I can't think of any potential confusing/breaking behaviour.

[michaelklishin]

Filed it here and not in https://github.com/rabbitmq/rabbitmq-cli because the wrappers are in this repo at the moment.

[wyardley]

Sorry, what I meant is (in terms of it being drastic), is just concern about causing an unintended consequence to the user when we start mucking around with default env in modules. For Puppet, at least, it should be only in the calls related to the module, but still I worried that it could cause unpredictable behavior (not to mention the political issue of what specific locale would be the default).

Either way, it's good to have confirmation that setting it to en_US.UTF-8 shouldn't cause an issue -- I didn't know whether users could create resources for which this might cause a problem in certain corner cases.

[michaelklishin]

We understand that there will be tension about whether this is a good idea and what default should be used. IIRC this is exactly why we didn't do it before. Requiring every user to configure locale settings would also suck.

FWIW our CLI tools are currently not localised and it's unlikely to change in the medium term, so there's less potential for breakage.

[michaelklishin]

@gerhard might have an opinion on this :)

[dumbbell]

Forcing the locale to something.UTF-8 will silence the warning, but it won't solve the actual problem: I suppose Elixir expects UTF-8 encoded input and produces UTF-8-encoded output. If the locale is forced just for the rabbitmqctl escript, how the terminal/shell/other tools started in a pipe know about it? If the session is configured with a charset incompatible with UTF-8 or US-ASCII, forcing the locale like that will break data exchanged between the CLI and the outside world.

IMHO, the caller (whether it is an interactive shell session or a configuration management tool) is responsible for setting an appropriate locale because only it knows about the environment/session.

Another minor issue would be that the forced locale is unavailable. But Erlang/Elixir may not call setlocale(3) or may not display a warning if the function fails, so perhaps it's a non-issue. But here are examples with locale(1) and Perl which do log a warning:

$ LC_ALL=en_GB.ISO-8859-15 locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.ISO-8859-15"
...

$ LC_ALL=fr_FR.UTF-8 perl --help
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = "fr_FR.UTF-8",
	LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").

Usage: perl [switches] [--] [programfile] [arguments]
  -0[octal]         specify record separator (\0, if no argument)
...

If Elixir does that at some point, we are back to square 1.

[michaelklishin]

Closing in favor of rabbitmq/rabbitmq-website#512. We'll update the Chef cookbook as well. Thank you for bringing this up, @wyardley.

[gerhard]

Thank you for the ping @michaelklishin, great resolution, fully agree with @dumbbell