Selecting a pipenv environment not working?

[dfee]

• VS Code version: Version 1.24.0-insider (1.24.0-insider) / 8a07c8d935998d1b1153dde0c5b337189d35cea0
• Extension version (available under the Extensions sidebar): 2018.4.0
• OS and version: MacOS 10.13.4
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.6.5
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pipenv
• Relevant/affected Python packages and their versions: n/a

Actual behavior

Inability to select my Python interpreter

Expected behavior

Expected the ability to select my Python interpreter

Steps to reproduce:

Input an interpreter to "Select Python Interpreter": https://youtu.be/QdZXOEWS7LQ (1min recording)

Logs

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

recent call last):
  File "/usr/local/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==9.0.3', 'console_scripts', 'pipenv')()
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 676, in main
    _verify_python3_env()
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/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
	at PipEnvService.<anonymous> (/Users/dfee/.vscode-insiders/extensions/ms-python.python-2018.4.0/out/client/interpreter/locators/services/pipEnvService.js:113:31)
	at Generator.next (<anonymous>)
	at fulfilled (/Users/dfee/.vscode-insiders/extensions/ms-python.python-2018.4.0/out/client/interpreter/locators/services/pipEnvService.js:15:58)
	at <anonymous> (at PipEnvService.<anonymous> (/Users/dfee/.vscode-insiders/extensions/ms-python.python-2018.4.0/out/client/interpreter/locators/services/pipEnvService.js:120:25))
t.log @ /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:267

After re-opening the editor I get the following message:

[dfee]

I noticed that the helper text for "python.venvPath" is: "Path to folder with a list of Virtual Environments". So, I updated that config setting to simply:

{
    "python.venvPath": "/Users/dfee/.local/share/virtualenvs"
}

I'm not sure what that setting actually does. I'm still unable to select an interpreter.

[DonJayamanne]

• venvPath, you need to put in the path to the directory (not the executable)
• As for the error message you are getting above this has been reported a number of times in this repo:
  • Please could you try initializing the env variables ($LC_ALL, $LANG) as described here http://click.pocoo.org/5/python3/

Note: This is an error returned by one of the packages that pipenv relies on.

[dfee]

Ah, I noticed that the correct setting is "python.pythonPath". I set it, and it works. I'm still not clear why the GUI option doesn't work.

{
    "python.venvPath": "/Users/dfee/.local/share/virtualenvs",
    "python.pythonPath": "/Users/dfee/.local/share/virtualenvs/sqlademo-d4pSLlIn"
}

I now really don't understand why I would supply "python.venvPath". But alas, I have an interpreter selected.

For what it's worth, I didn't have to go through manually configuring the "python.pythonPath" setting like a month ago.

[dfee]

@DonJayamanne sorry for being dense here, but when you say initialize those variables, are you suggesting I simply export those variables in a shell, and launch code-insiders from there?

$ export LC_ALL=en_US.utf-8
$ export LANG=en_US.utf-8
$ code-insiders

That works... I'm just wondering if there is a way to configure VSCode to do this itself? I presume it's not this, and I can't find any other relevant settings with a search for "environment".

  // Object with environment variables that will be added to the VS Code process to be used by the terminal on OS X
  "terminal.integrated.env.osx": {},

[DonJayamanne]

Since you are using a mac, please could you try initializing those variables in your ~/.bash_profile file

[dfee]

I tried that, and it didn't work. I don't know why it would work either, as that isn't how environment variables are inherited in child processes. Is VSCode reading in my ~/.bash_profile at some point during initialization?

~/code/sqlademo
$ ps -few | grep VSCode
  501  8892     1   0  9:58AM ??         0:00.04 /Applications/Visual Studio Code - Insiders.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --no-rate-limit --no-upload-gzip --database=/var/folders/bc/_0x9ct791_337krql7zf5vlr0000gn/T/VSCode Crashes --metrics-dir=/var/folders/bc/_0x9ct791_337krql7zf5vlr0000gn/T/VSCode Crashes --url=https://rink.hockeyapp.net/api/2/apps/21a48a66799e47fea4f52c0ff81e803d/crashes/upload --handshake-fd=60
  501  9705  8478   0 10:12AM ttys002    0:00.00 grep VSCode

~/code/sqlademo
$ ps eww 8892
  PID   TT  STAT      TIME COMMAND
 8892   ??  S      0:00.04 /Applications/Visual Studio Code - Insiders.app/Contents/Frameworks/Electron Framework.framework/Resources/crashpad_handler --no-rate-limit --no-upload-gzip --database=/var/folders/bc/_0x9ct791_337krql7zf5vlr0000gn/T/VSCode Crashes --metrics-dir=/var/folders/bc/_0x9ct791_337krql7zf5vlr0000gn/T/VSCode Crashes --url=https://rink.hockeyapp.net/api/2/apps/21a48a66799e47fea4f52c0ff81e803d/crashes/upload --handshake-fd=60 TMPDIR=/var/folders/bc/_0x9ct791_337krql7zf5vlr0000gn/T/ __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 SHELL=/usr/local/bin/bash HOME=/Users/dfee Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.Ar4luGFO9b/Render SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.xIM8v2Wppm/Listeners PATH=/usr/bin:/bin:/usr/sbin:/sbin LOGNAME=dfee XPC_SERVICE_NAME=0 USER=dfee XPC_FLAGS=0x0 GOOGLE_API_KEY=AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q VSCODE_NODE_CACHED_DATA_DIR_8831=/Users/dfee/Library/Application Support/Code - Insiders/CachedData/8a07c8d935998d1b1153dde0c5b337189d35cea0 VSCODE_NLS_CONFIG={"locale":"en-us","availableLanguages":{}} VSCODE_LOGS=/Users/dfee/Library/Application Support/Code - Insiders/logs/20180508T095805 VSCODE_IPC_HOOK=/Users/dfee/Library/Application Support/Code - Insiders/1.24.0-insider-main.sock VSCODE_PID=8831

[DonJayamanne]

To be honest, I don't really know how environment variables are defined for GUI apps on OSX.
However when I try this at my end it seems to work. Then again, I see your point, based on the docs ~/.bash_profile might not be picked by gui apps.
Either way, it does seem to work at my end.

[dfee]

@DonJayamanne OSX is a strange beast. I don't know. I didn't get the error when starting up VSCode (not from the terminal, and after adding those two configurations to my .bash_profile), and I'm also not seeing the environment variables for the VSCode process. Maybe there is some launch pattern for whatever executes pipenv --venv by VSCode, which actually happens in a subprocess?

So, I think we can move on from the pipenv problem, but I still think the Select Python Interpreter prompt might be broken.

[DonJayamanne]

Please could you try the following:

• Keep the changes to the ~/.bash_profile
• Open the following file in VS Code:
  /Users/dfee/.vscode-insiders/extensions/ms-python.python-2018.4.0/out/client/interpreter/locators/services/pipEnvService.js
• Go to line 108 (where you'll find the code const result = yield this.process.exec(execName, [arg], { cwd: rootPath, env });
• Modify the code as follows, (all you need to do is add the argument shell as follows):
  const result = yield this.process.exec(execName, [arg], { cwd: rootPath, env, shell:true });
• Reload VS Code
• Let me know whether pipenv works now (open VS Code and check whether it detects pipenv when selecting using the command Select Interpreter.

[dfee]

I applied the change, saved the file and restarted VSCode Insiders. Is this what I'm supposed to see?

[DonJayamanne]

• Have you opened the same workspace (the one with the Pipfile), the same one you had opened earlier?
• You should see just the pipenv environment(s), not the list you have displayed above.
• I'm assuming you no longer get the message Workspace contains pipfile but....

[dfee]

I'm no longer getting that Workspace contains pipfile but... message, but I stopped seeing that after adding the environment variables.

I created another video. This video contains:

1. creation of a new pipenv
2. reload of the project (not restart) through close / reopen
3. verification of the change you'd requested i make
4. demonstration that no venv is autoidentified, but I am able to activate the pipenv in the terminal

[ericsnowcurrently]

@dfee, sorry for the delay in getting back to you. If the extension detects a pipenv then only that pipenv is used. Any other virtualenvs (or other Python interpreters) are ignored. In order to see other interpreters (e.g. in virtual envs), you must delete the pipfile. So if you have a pipenv set up for the project then that should be the only interpreter you can select. From your description it sounds like that's the situation. Please verify.

[brettcannon]

I just opened #1800 to track the removal of hiding other interpreters when using pipenv.

[dfee]

@ericsnowcurrently correct. I'll defer to you whether to close (up to your process).

[brettcannon]

I'm going to close then in favour of the feature request. Thanks for your patience in explaining the issue, @dfee .