-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Debugger won't work when executed using pipenv, integratedTerminal and python.terminal.activateEnvironment #4463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for opening this issue and providing so much helpful details, @Kurolox. We'll look into it. |
(from @fearedbliss in #4223 (comment)) I'm also experiencing the same issue. I'm on Fedora 29, Running VS Code 1.31.1, with Django, Pipenv, and 3.6.8. I've been using VS Code/Python Extension/Pipenv for months and it was fine. Reverting to the older version helped me as well, but I'm glad to update to the new version and help debug this issue. although in my situation I don't have stop on entry and it just doesn't work. This is my current launch setting (which is the default):
|
(my response in #4223 (comment)) @Kurolox, @fearedbliss, thanks for you interest in helping us fix the problem! It looks like the problem you are seeing isn't quite the same thing as the "stopOnEntry" bug we're addressing here. Given what you both have said, it may be pipenv related, though it could still be indirectly related to the "stopOnEntry" bug. Regardless, @Kurolox (or @fearedbliss), would you mind opening a separate issue for the problem you are seeing. Please refer back to this issue, especially your comment and @fearedbliss's specifically. Mention me and @fearedbliss (so we get notified). You can both open new issues if you like, on the off chance that they are actually different problems. However, you probably have the same problem so let's start with one new issue. I'd be glad to open the new issue for you, but the report will be a little less confusing if it comes from you directly. Just let me know. If we later determine that the "stopOnEntry" bug is actually the problem for you too then we'll just close the new issue as a duplicate. However, I think it's unlikely that it's the same problem. @Kurolox, please indicate on the new issue if you are debugging a Django app (i.e. using the default "Python: Django" launch config), like @fearedbliss is. @fearedbliss, please indicate on the new issue if setting You both can reply here too, but I'd rather avoid splitting the conversation across multiple issues at this point. :) |
(from @fearedbliss in #4223 (comment)) @ericsnowcurrently You can open the other commit. I tested your suggestion about activateEnvironment, I put
in my settings.py and it worked :D. So what does this mean exactly? Is there a regression with the activating environment stuff compared to the previous version? Or is activating the environment something new? |
(from @louyihua in #4223 (comment)) @fearedbliss If "python.terminal.activateEnvironment": true VSCode tries to run
But the completed command line should be:
Surely the above incomplete command line will not launch the debug server. |
(from @fearedbliss in #4223 (comment)) @louyihua yup pretty much. Before the 2019.1 update, (and after 2019.1 with the activateEnvironment disabled), it has the same behavior which works correctly:
In my situation I am using pipenv but I never needed to activate the pipenv shell before running, it was actually perfectly fine to maintain the existing behavior which was to select the python interpreter that's inside of the pipenv shell, and then run the debugging as normal. So I'm still using the python version that I created when I ran the pipenv installation for a particular version of Python for w/e directory I'm in, but no other stuff is needed for my particular use case in VSCode. However if after this is fixed, activating the environment still allows everything to work, I'm also fine using the default. |
(from @fearedbliss in #4223 (comment)) Also I forgot to mention, in my particular situation you would see an output similar to as follows:
After this it would just basically stall and I'll get an error |
@DonJayamanne, any insights on this issue? |
Dup of #4203 |
Environment data
1.31.1 1b8e8302e405050205e69b59abb3559592bb9e60 x64
2019.1.0
4.20.10-arch1-1-ARCH
N/A
Expected behaviour
Starting the Python Debugger in VS Code, and being able to use it properly
Actual behaviour
After launching the debugger, it will get stuck for some time (Around 10-15 seconds), then it will display a pop-up saying
Timeout waiting for debuger connection
, which will prompt you to Open thelaunch.json
configuration file. This happens on a stocklaunch.json
configuration, though.Steps to reproduce:
Other stuff to mention
settings.json
file is the one generated by VS Code and unmodified. For the purposes of this test I've been usingPython: Current File (Integrated Terminal)
, which is set up as follows:"python.terminal.activateEnvironment": false
will make the debugger work properly. Another workaround is setting the terminal toexternalTerminal
ornone
, rather thanintegratedTerminal
.print("Hello world!")
will cause this issue to happen.PIPENV_VENV_IN_PROJECT=true
setting, so all the virtual environments I'm generating are inside the project folders ( usually in${workspaceFolder}/.venv
)/usr/bin
) will also make the debugger work properly, even with an integrated terminal and"python.terminal.activateEnvironment": true
, though there's no virtualenv being activated in this scenarioWorkarounds
Any of these will do.
"python.terminal.activateEnvironment": false
in yoursettings.json
launch.json
profile you're using, set up either"console": "integratedTerminal"
or"console": "none"
Logs
Output for
Python
in theOutput
panel (View
→Output
, change the drop-down the upper-right of theOutput
panel toPython
)Output from
Console
under theDeveloper Tools
panel (toggle Developer Tools on underHelp
; turn on source maps to make any tracebacks be useful by runningEnable source map support for extension debugging
)The text was updated successfully, but these errors were encountered: