With VS Code 1.27.0 on Mac, I'm setting a breakpoint with Python debugger. I've setup a launch config to run Celery. Celery does stop in my code, if I move the breakpoint I can change what's logged before it stops. So it is stopping.
However the VS Code UI does not show that its stopped, and I cannot inspect anything or do anything. VS Code launches celery something like this:
cd /Users/bob/project ; env "PYTHONPATH=/Users/bob/.vscode/extensions/ms-python.python-2018.8.0/pythonFiles/experimental/ptvsd" /usr/local/bin/python3 -m ptvsd --host localhost --port 49650 /Library/Frameworks/Python.framework/Versions/3.5/bin/celery -A pipeline.app worker -l info -f worker.log
I'm unclear why it needs ptvsd and ports since it's not doing remote debugging. If I make a completely stand-alone script and run it with Python: Current File it debugs fine.
The launch.json entry is like:
{
"name": "Python: Celery",
"type": "python",
"request": "launch",
"program": "/Library/Frameworks/Python.framework/Versions/3.5/bin/celery",
"args": [
"-A",
"my_module.app",
"worker",
],
},
There is a specific debugger, celery.contrib.rdb
See if that makes it work
Related
When using VSCode and fish as the default user shell, I cannot overwrite the environment variables set by fish in VSCode launch configs.
Example:
in $XDG_CONFIG_HOME/fish/config.fish:
set -x FOO BAR
In .vscode/launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "My launch",
"type": "cppdbg",
"request": "launch",
"program": "/bin/sh",
"args": ["-c", "echo $FOO"],
"environment": [
{
"name": "FOO",
"value": "OVERWRITTEN"
}
],
"cwd": "${workspaceFolder}"
}
]
}
I expected this to print OVERWRITTEN, but I got BAR.
It seems VSCode is setting the environment variable, then running the user shell to run my program. Why do I have this behavior with fish but not bash for example? Is there a way to avoid using the user shell? What would be a good practice?
So far, the best fix I could get was to wrap my fish.config in a if status is-interactive.
The environment portion causes VSCode to launch the program (in this case, fish) with an environment variable set. The program may then overwrite that variable, which is what the set command does.
This will also occur with bash or any shell. The most likely reason you are not seeing this with bash is that bash only sources ~/.bashrc for interactive shells (docs on this). If you were to set $BASH_ENV to a file, bash would execute that and potentially overwrite environment variables in the same way.
To avoid overwriting the variable in fish, you can conditionalize it on whether you are interactive or not:
status is-interactive && set -x FOO BAR
alternatively you can detect if it's already set:
set -qx FOO || set -x FOO BAR
This second approach implements a "default" value for the variable, allowing the environment to take precedence.
Every time I debug (using an external Terminal) it opens a new session.
Is it possible to reuse the same window / session?
Or if not to close the current one so it doesn't keep opening a new window?
Similar questions are related to the internal Terminal.
I'm using iTerm2 on macOS.
Here's my launch.json config:
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Current File (External)",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "externalTerminal",
"python": "/Users/josip/.virtualenvs/myproject-JnedzVU7/bin/python",
},
{
"name": "Python: Current File",
"type": "python",
// "justMyCode": false,
"request": "launch",
"program": "${file}",
"console": "integratedTerminal"
},
]
}
This problem only exists with iTerm, as everything works as expected with Terminal and the existing session is used for successive run/debug executions.
The difference in behaviour is due to the way the applescripts that send the debugging command to the external terminal are written. The script for Terminal (readable gist) contains logic for finding available session and telling the app to run the command with that session. Conversely, the script for iTerm (readable gist) is about as simple as can be for sending commands to run in iTerm.
While the Terminal script has functions for determining the right session and window to use, the iTerm script has only the following (excl. validation steps which are identical):
tell application "iTerm"
activate
set new_term to (create window with default profile)
delay 1
tell new_term
tell the current session
write text cmd
end tell
end tell
end tell
This is where the script is loaded and used to run the command in the configured terminal
I've scanned the iTerm scripting documentation and it should be possible to replicate the Terminal behaviour using the iTerm APIs if you want to make a feature request or submit a pull request with the change.
Is there a way to send messages to gdb programmatically in tasks.json? I can send messages in the debug window, but I would like to automate this.
I am using a microcontroller and openocd. I would just like to do things like re-flash the chip through gdb (remote connection) without having to type commands out every time, and integrate gdb commands into my build tasks.
Pass commands to gdb with -ex arguments:
{
"label": "Gdb help",
"command": "gdb",
"type": "shell",
"args": [
"-q",
"-ex", "help",
"-ex", "quit"
],
"problemMatcher": []
}
But I would propose to write a command file (https://sourceware.org/gdb/onlinedocs/gdb/Command-Files.html). So you will be able to reuse it in many places. The controller's basic initialization could be interesting for debugging (launch.json file). Command file could be passed via -command=file argument.
I'm debugging a Python script. My configuration looks something like this:
{
"name": "debug script.py",
"type": "python",
"request": "launch",
"program": "/path/to/script.py",
"console": "integratedTerminal"
}
When running the script, I need to prefix it with an executable aws-access to give myself access to certain resources on AWS (otherwise I get Permission Denied errors):
aws-access python script.py
How can I add this prefix to the debug command?
Note this is easy to do when executing my code using the Code Runner plugin:
"code-runner.executorMap": {
"python": "aws-access $pythonPath -u $fullFileName"
}
It's a little less smooth than usual, but here's how to do it:
You'll need to have debugpy installed
To initiate the debugging, you'll need a separate function or script that waits for the debugger to attach. I have mine in a separate script that looks like:
import debugpy
debugpy.listen(5678)
debugpy.wait_for_client()
from foo import bar
bar.run()
Where bar.run() is what you're trying to debug.
You'll then need to specify a launch.json configuration for VSCode - you can create this yourself in the project directory that you're trying to debug under /.vscode/launch.json or create one from within VSCode
launch.json should look something like:
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Attach Standard",
"type": "python",
"request": "attach",
"connect": {
"host": "localhost",
"port": 5678
}
}
]
}
a general debugging flow being:
within the VSCode terminal, set up your aws credentials either with environment variables, or something like aws-vault (which in turn, will set environment variables)
from the same terminal, run the debug function or script e.g. python debug_script.py
run the function or script with debugging from the VSCode UI(again, I use a script as it makes this part easier and less invasive to your code)
It will respond to UI debug points set in VSCode, and also on debugpy.breakpoint() within the code. More importantly, it will use the same terminal session you've set your AWS environment variables in.
Another alternative is to run:
saml2aws exec --exec-profile [your-profile-name] --session-duration=3600 -- $SHELL
in your VS terminal. Upon subsequent debugging executions, you will stay authenticated (up to the session duration).
In my workspace settings I have
{
"terminal.integrated.shellArgs.linux": [
"-c",
"yarn custom_shell"
],
}
which launches a custom shell that prompts for user input on startup.
When I create a launch.json config that launches using the integrated terminal my yarn custom_shell command will run and wait for input, causing the launch command supplied by VS Code to fail to run. This same issue occurs for extensions that launch a program in my integrated terminal.
Is there a way to launch the integrated terminal with terminal.integrated.shellArgs only when it is an interactive user shell, not a shell started by an extension or launch.json config?
I think a good solution is to keep the integrated shell to behave as expected and to use shell-launcher extension for hacking different shells in vscode (it might also save you the need to wait for user input in your custom shell):
"shellLauncher.shells.linux": [
{
"shell": "bash",
"args": ["-c yarn custom_shell"],
"label": "my_custom_yarn_shell"
}
]