Same thing to me, but you can change the key-value to

{
    "version": "0.2.0",
    "configurations": [
        {
            ...,
            "purpose": ["debug-in-terminal"],
            ...
        }
    ]
}

Works for me 😃

Maybe if those users never develop library code, but then why would they use VS Code and not Jupyter or something. As a library developer, no week passes without me wanting to set a breakpoint in a 3rd party library.

I think it’d be much more discoverable to add a python.debug.justMyCode setting or so to define the default. That way people don’t have to slog through years of outdated StackOverflow questions to figure out the specific launch.json config that happens to work and also doesn’t change a bunch of other things about how tests are run.

FYI this comes off as accusatory as if I am making up the feedback we received about this, which I don’t think you meant for it to.

Thanks for the feedback. You’re right, I didn’t. The quotes were simply because I cited your wording.

If you would like us to reconsider the default value for justMyCode, please open a new feature request.

Reconsider the default or make it configurable, yes. Done: #21748

Could we just disable the “justMyCode” default behavior?

As in make "justMyCode": false be the default? If that’s what you’re asking, the answer is unfortunately no. That’s what the default used to be and the feedback we got from folks is they didn’t want that, so we swapped the default to what it is today. It’s unfortunately one of those situations where we can’t please all the people all the time, so we have to choose something and deal with the fact people don’t like it.

Also, going by upvotes is going to have a survivorship bias. If an issue is bad enough people simply uninstall and go back to their old IDE, they aren’t going to bother finding an issue on github and upvoting.

Maybe, but we have to use something to try and keep our issue tracker under control and know what the community wants. Otherwise we run the risk of prioritizing niche needs at the cost of the wider user base (which happened in the past), which also leads to a loss of users. Once again, we can’t please all the people all the time, so we have to choose some approach.

Actually, I see various paths forward, including one where we add a setting and then just read from it in applyDefaults in debugLauncher.ts, which I think is the ideal case. When trying to test the debugger, without any changes, it seems to hang. I do notice that testing debugpy seems to have directions about cloning the repo into extensions but its not fully clear to me what that entails or how that works when operating out of a dev container. I can eventually figure this out, but if someone happens to know the process or expected behavior of the top of their head, that would be appreciated. I’m going to take a break from working on this for now but will check back later.

Also, going by upvotes is going to have a survivorship bias. If an issue is bad enough people simply uninstall and go back to their old IDE, they aren’t going to bother finding an issue on github and upvoting.

Was this prioritized? Its kind of a big deal. It’s very jarring to get a cryptic error message on something so common, and stepping into library code isn’t an usual use case - the library code is often also you or your organization’s code. I really hate this kludge method to enable stepping into library code. For many devs, it gives a poor first impression when they see a run configuration that’s to be ignored. It should ideally just be a check box.

Using debug-in-terminal results in the run configuration no longer serving its purpose for tests.