Black exits with exception when executed from vscode but works when used directly on shell

Environment data

• VS Code version: 1.24.1
• Extension version (available under the Extensions sidebar): 2018.5.0
• OS and version: macOS Sierra 10.12.6
• Python version (& distribution if applicable, e.g. Anaconda): versions 2.7.14 & 3.6.5 (where black is installed)
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): pyenv/virtualenv
• Relevant/affected Python packages and their versions: black 18.6b2

Actual behavior

When using the command Format document in vscode with black as the chosen formatter, the command fails and leaves a RuntimeError in the console.

The project is in a python 2.7 environment, but black is installed in a python 3.6.5 env and its path is updated in settings.

{
  "python.formatting.provider": "black",
  "python.formatting.blackPath": "/Users/damon/.pyenv/versions/3.6.5/bin/black"
}

In the terminal, while inside of the 2.7 virtualenv, I’m able to call black directly without errors.

I’m also able to use the deprecated joslarson.black-vscode extension without errors.

Expected behavior

Black formats the python file.

Steps to reproduce:

1. Select a python 2.7.14 virtual env as the interpreter.
2. Install black in a separate python 3.6.5 env.
3. Update settings.json to use black as the python.formatting.provider and set the python.formatting.blackPath to the 3.6.5 environment’s path for bin/black.
4. Open a python file and call Format document.

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

Formatting with black failed.
Error: Traceback (most recent call last):
  File "/Users/damon/.pyenv/versions/3.6.5/bin/black", line 11, in <module>
    sys.exit(main())
  File "/Users/damon/.pyenv/versions/3.6.5/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/Users/damon/.pyenv/versions/3.6.5/lib/python3.6/site-packages/click/core.py", line 676, in main
    _verify_python3_env()
  File "/Users/damon/.pyenv/versions/3.6.5/lib/python3.6/site-packages/click/_unicodefun.py", line 118, in _verify_python3_env
    'for mitigation steps.' + extra)
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment.  Consult http://click.pocoo.org/python3/for mitigation steps.

This system lists a couple of UTF-8 supporting locales that
you can pick from.  The following suitable locales where
discovered: af_ZA.UTF-8, am_ET.UTF-8, be_BY.UTF-8, bg_BG.UTF-8, ca_ES.UTF-8, cs_CZ.UTF-8, da_DK.UTF-8, de_AT.UTF-8, de_CH.UTF-8, de_DE.UTF-8, el_GR.UTF-8, en_AU.UTF-8, en_CA.UTF-8, en_GB.UTF-8, en_IE.UTF-8, en_NZ.UTF-8, en_US.UTF-8, es_ES.UTF-8, et_EE.UTF-8, eu_ES.UTF-8, fi_FI.UTF-8, fr_BE.UTF-8, fr_CA.UTF-8, fr_CH.UTF-8, fr_FR.UTF-8, he_IL.UTF-8, hr_HR.UTF-8, hu_HU.UTF-8, hy_AM.UTF-8, is_IS.UTF-8, it_CH.UTF-8, it_IT.UTF-8, ja_JP.UTF-8, kk_KZ.UTF-8, ko_KR.UTF-8, lt_LT.UTF-8, nl_BE.UTF-8, nl_NL.UTF-8, no_NO.UTF-8, pl_PL.UTF-8, pt_BR.UTF-8, pt_PT.UTF-8, ro_RO.UTF-8, ru_RU.UTF-8, sk_SK.UTF-8, sl_SI.UTF-8, sr_YU.UTF-8, sv_SE.UTF-8, tr_TR.UTF-8, uk_UA.UTF-8, zh_CN.UTF-8, zh_HK.UTF-8, zh_TW.UTF-8

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)

mainThreadExtensionService.ts:44 Error: ENOENT: no such file or directory, open 'extension-output-#6'
	at Object.fs.openSync (fs.js:584:18)
	at Object.module.(anonymous function) [as openSync] (ELECTRON_ASAR.js:173:20)
	at Object.fs.readFileSync (fs.js:491:33)
	at Object.fs.readFileSync (ELECTRON_ASAR.js:505:29)
	at TrailingSpaces.freezeLastVersion (/Users/damon/.vscode/extensions/shardulm94.trailing-spaces-0.2.11/out/src/trailing-spaces/trailing-spaces.js:266:51)
	at /Users/damon/.vscode/extensions/shardulm94.trailing-spaces-0.2.11/out/src/trailing-spaces/trailing-spaces.js:56:19
	at e.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:96:764)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:727:112
	at e.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:96:764)
	at e.$acceptDocumentsAndEditorsDelta (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:725:330)
	at e._doInvokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:636:832)
	at e._invokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:636:550)
	at e._receiveRequest (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:635:631)
	at e._receiveOneMessage (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:635:400)
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:634:315
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:637:395
	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:95:432
	at e.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:96:764)
	at Socket.<anonymous> (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/node/extensionHostProcess.js:154:338)
	at emitOne (events.js:96:13)
	at Socket.emit (events.js:191:7)
	at readableAddChunk (_stream_readable.js:178:18)
	at Socket.Readable.push (_stream_readable.js:136:10)
	at Pipe.onread (net.js:560:20)

[brettcannon]

This is a known issue with Black’s use of the Click library which makes these demands. It means you need to make sure you set your LANG and LC_ALL in your environment such that when node does a system call to execute Python for Black it will pick up those variables. The Black extension probably doesn’t trigger for this because they just inject the values, but since we have to support other tools which might not like that we currently don’t do the injecting.

[brettcannon]

@blackrobot I would try setting LC_ALL in the config file that your shell reads for login shells (e.g. .bash_profile for bash). I don’t think we use an interactive shell for this and so e.g. .bashrc won’t work.