Ignore pipenv when python.pythonPath is already set
See original GitHub issueEnvironment data
- VS Code version: 1.23.0
- Extension version (available under the Extensions sidebar): 2018.4.0
- OS and version: Windows 10 Enterprise 2016 LTSB 10.0.14393.0
- Python version (& distribution if applicable, e.g. Anaconda): Python x64 3.6.5
- Type of virtual environment used (N/A | venv | virtualenv | conda | …): pipenv
- Relevant/affected Python packages and their versions: pipenv 11.10.0
Actual behavior
When I open my project folder I get the following error:
Expected behavior
I should get no error. My .vscode/settings.json
is properly configured. This same project folder was working a week ago, but now when I open it I get the error cited above.
Workspace settings
{
"python.pythonPath": "C:\\Users\\<username>\\.virtualenvs\\amazing-project-xyz12Abc\\scripts\\python.exe"
}
Steps to reproduce:
- Open a project folder configured to use pipenv
Logs
Output for Python
in the Output
panel (View
→Output
, change the drop-down the upper-right of the Output
panel to Python
)
##########Linting Output - pylint##########
No config file found, using default configuration
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
Output from Console
under the Developer Tools
panel (toggle Developer Tools on under Help
)
console.ts:136 [Extension Host] vscode-icons is active!
console.ts:136 [Extension Host] Error: No virtualenv has been created for this project yet!
at PipEnvService.<anonymous> (C:\Users\<username>\.vscode\extensions\ms-python.python-2018.4.0\out\client\interpreter\locators\services\pipEnvService.js:113:31)
at Generator.next (<anonymous>)
at fulfilled (C:\Users\<username>\.vscode\extensions\ms-python.python-2018.4.0\out\client\interpreter\locators\services\pipEnvService.js:15:58)
at <anonymous>
t.log @ console.ts:136
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:12 (1 by maintainers)
Top Results From Across the Web
Why is pipenv telling me the wrong version of python?
With pipenv you simply have to set the WORKON_HOME folder then pipenv install should create your virtual env under that same folder. Every...
Read more >Advanced Usage of Pipenv - Read the Docs
This causes Pipenv to ignore changes to the Pipfile and (more importantly) prevents it from adding the current environment to Pipfile. lock ....
Read more >Configure a Pipenv environment | PyCharm Documentation
Run the following command to find the user base's binary directory: $ python -m site --user-base · Add bin to this path to...
Read more >Pipenv & Virtual Environments
While pip can install Python packages, Pipenv is recommended as it's a higher-level tool ... You can set your user PATH permanently in...
Read more >pipenv Documentation - Read the Docs
You can set your PATH permanently by modifying · ~/.profile. On Windows you can find the user base binary directory by running python...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Sorry then, should have opened a ticket on pipenv. Anyway, just to give a proper response to this ticket: I deleted my old pipenv folder and re-install pipenv running
pipenv install
inside the project folder and now everything is OK again and I have a newC:\Users\<username>\.virtualenvs\amazing-project-wbFrJQp8
pipenv folder.Sorry for commenting on a closed ticket, but I just got hit with that too. The behaviour is VSCode refuses to see pipenv environment and cmd/PS can see it just fine. I did some debugging and it turns out (on Windows) cmd/PS always use an uppercase letter for the drive while VSCode started passing a lowercase letter. This causes pipenv to count a different hash to the virtualenv directory and hence the difference. This SHOULD be fixed in pipenv I guess (but could also be handled in getPipenvWorkingDirectory).
Nevermind, pipenv fixed this in 10.0.0 I just needed to upgrade 😃