-
Notifications
You must be signed in to change notification settings - Fork 26
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
Convert all non-string configuration properties in debug #115
Comments
Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue. |
/cc @int19h |
Note that we already did this for Given that it's the second property like that, and that it's hard to predict all the scenarios in which variable substitution might be useful for one property or another, I feel like this should be generalized to all numeric properties. On debugpy side this would be easy, since there's a common path for all typed property queries. However, |
Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future. We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most. |
I found this issue as I was preparing to make the exact same feature request! I have a situation where a team of developers needs to actively debug multiple containerized micro-services at once. This works just fine, but the caveat is that that everyone has to modify their local |
Definitely need this! |
Isn't this a dupe of microsoft/vscode-python#18841? |
18441 handled this case for the |
I see that I actually commented to that above and forgot about it! 🤦♂️ For "listen", the fix had to be on debugpy side - it was actually more extensive that that and covered all numeric debug configuration properties, not just the port. But for "connect" (or the legacy top-level "port"), it's vscode-python that has to parse the port to establish the connection, and it currently just assumes that it's a valid int: This is the part that needs fixing. Although I would recommend doing the same thing that debugpy did, and fix this for all non-string configuration properties. |
I'm confused as to why this got transferred - it's already implemented on debugpy side for all numeric properties that debugpy handles, and the remaining work is for the extension handling of port number in connect scenarios. |
@int19h because all debugger stuff related to VS Code and Python should end up here. Why do you think it stay on the core extension side? |
Sorry, I got confused about which repo it is, I thought it ended up in the core debugpy repo where it was filed originally. You're right, this is the proper tracker for it. |
Are there short verif steps for this feature? |
This issue was solved in the Python Debugger Extension. |
LGTM. Thanks! |
Requested feature
Support port numbers in attach debug configurations as strings rather than numbers exclusively.
Motivation
The attach debug configurations expect a number as port number rather than a string. This prevents variable substitution in
launch.json
. As an example, the following configuration raises an error on theport
key:Incorrect type. Expected "number"
.Use case
Assume that you have to debug your application by attaching to a running process. Assume that you package and debug the application into a container by attaching VSCode to the running container. Finally, assume that you have to debug parallel instances of the application on your local machine. In this scenario each debugger must use a distinct port (this is the case for containers in a podman pod at least because they share the same network). The port could be supplied as an environment variable to each container.
The text was updated successfully, but these errors were encountered: