We decided to use a different method to resolve this issue.

In D8039#118719, @yuja wrote:

What do you think about this approach:
1. The server detects that LC_TYPE is coerced.
2. When handling the "validate" command, the server sends back "invalidate this server, and fallback to original hg" response.
This makes chg/non-chg behave consistently with some startup overhead in mis-configured environment. The chg client can potentially print a warning to remind the user to fix their environment.

That could be, but if we do want to make chg/hg behavior consistent, maybe we
can adjust the hash computation logic?

1. client sends CHG_ORIG_LC_CTYPE or CHG_UNSET_LC_CTYPE when spawning server
2. they're kept in environ dict, but override LC_CTYPE while computing hash, and excluded from the hash
3. client does not send these variables over setenv command, but passes the validation because {CHG_ORIG_LC_CTYPE: x, LC_CTYPE: y} == {LC_CTYPE: x}.

I'll see how easy that is to implement and send a separate review request once I have it working.

In D8022#118428, @yuja wrote:

This would cause a difference in behavior between hg and chg. I don't know how big of an issue that would be.
hg: starts up, python coerces LC_CTYPE, hg spawns a non-python subprocess, LC_CTYPE is set to the coerced value
chg: starts up, python coerces LC_CTYPE, chg fixes it, hg spawns a non-python subprocess, LC_CTYPE is set to the original value (or unset).

I think a minor behavior difference is acceptable. I see this is the problem
of Python 3 design "the world is unicode", and IMHO we want to work around
the problem with minimal changes.

I prefer passing in (const char**)environ to hgc_setenv().

In D8022#118325, @yuja wrote:

Another idea. How about sending the true LC_CTYPE value as a command
argument so the env mangling can be reverted?

1. spawn hg serve --cmdserver chgunix ... with --daemon-postexec setenv:LC_CTYPE=$LC_CTYPE
2. runservice() overwrites LC_CTYPE to the specified value (undo coercing)
3. chgserver hashes the restored environ

Since the "coercing" is 100% useless for Mercurial, restoring LC_CTYPE
should be perfectly fine. And unlike setting PYTHONCOERCECLOCALE=0,
Python subprocesses can still see its own "coercing" results for better
or worse.

In D7620#112376, @dlax wrote:

This should be documented in mercurial/helptext/config.txt I think.

In D7617#112130, @mharbison72 wrote:

See D7065 and D7570. I didn't realize you could stack set: and the other patterns like this.

In D7506#111966, @dlax wrote:

In D7506#111947, @spectral wrote:

I don't think from . import show works generally.

I did that because test-check-module-imports.t complained otherwise when using from hgext import show:

hgext/phabricator.py:89: import should be relative: hgext

Also, there's already a similar from . import rebase in hgext/split.py so I thought that relative import was fine.
I'm happy to change if there's a solution, though.

I don't think from . import show works generally. I received errors because I imported phabricator via a path (pointing directly at the .py file, something like [extensions] phabricator = /home/spectral/src/hg/hgext/phabricator.py), not by doing something like extensions.phabricator=. I received the following errors:

In D7550#111235, @yuja wrote:

When the environment is empty (specifically: it doesn't contain LC_ALL,
LC_CTYPE, or LANG), Python will "coerce" the locale environment variables to be
a UTF-8 capable one. It sets LC_CTYPE in the environment, and this breaks chg,
since chg operates by:
- start hg, using whatever environment the user has when chg starts
- hg stores a hash of this "original" environment, but python has already set LC_CTYPE even though the user doesn't have it in their environment
- chg calls setenv over the commandserver. This clears the environment inside of hg and sets it to be exactly what the environment in chg is (without LC_CTYPE).
- chg calls validate to ensure that the environment hg is using (after the setenv call) is the one that the chg process has - if not, it is assumed the user changed their environment and we should use a different server. This will *never* be true in this situation because LC_CTYPE was removed.

Sigh. Can we work around this weird behavior by making chg do
putenv("PYTHONCOERCECLOCALE=0")? I think it's simple and more desired
behavior than the default of Python 3.