This project has moved and is read-only. For the latest updates, please go here.

Calling Debugger On Same Machine, but not in VS

May 16, 2013 at 6:21 PM
What is the path to the python debug exe and are there any arguments? We have a tool capable of calling the debugger for PyScript and PyDev for Eclipse and wanted to see if it was possible to call into debugger for PTVS.

May 16, 2013 at 7:28 PM
We don't have a debug executable for this, we use launcher scripts that we run with python.exe. Right now, all of these are internal implementation details that could change, though when we release 2.0 the script will be fixed. (This is currently hidden inside our install directory - note that this page hasn't been updated for 2.0 yet.)

However, because we're so tightly coupled to VS, you're unlikely to get access to much functionality. What are you hoping to achieve by doing this? It's possible that there is another approach that may work better.
May 16, 2013 at 7:56 PM
Thanks for reply.

So, I'm kind of new to this and not sure how it completely works. We have a tool ( 3rd party ) that calls PyScripter that allows you to debug a script. It is similar to having a breakpoint set and running within the PyScript IDE. They may be using something similar to what you described above, but not sure. I will check with the 3rd party vendor ).

I was hoping there would be a way for use to pass in the same scripts to PTVS that would allow use to debug it while using their tool. Again, I will check with them. I was just checking on the this post if it was possible with PTVS.

Thanks again
May 16, 2013 at 10:27 PM
It's theoretically possible, but we won't be supporting it (which means 3rd parties can look at our code and try and make it work, but we might break them in future releases).

Most of the value of our debugger comes from the VS side of things, since the Python side is largely just using the standard support. If you would rather use VS than PyScripter (and note that we have instructions on our install page on how to get VS+PTVS without paying for VS), then that's the best way to use our debugger.

If you're happy with PyScripter, trying to use our debugger without VS won't give you any improvement.
May 18, 2013 at 12:09 AM
Is it possible ( from a separate process; i.e. command prompt or other app ) to pass scripts to open in PTVS? If so, could you show an example?

May 22, 2013 at 5:58 PM
Edited May 22, 2013 at 5:59 PM
To open a file in the editor, you can pass it directly to devenv (which is actually <VSInstallDirectory>\Common7\IDE\
If you have a .pyproj or .sln file, you can pass these instead:
devenv MyProject.pyproj
If you want to open VS and start debugging immediately, you can specify /Run:
devenv /Run MyProject.pyproj
Unfortunately, there is no way to start debugging without a project file - devenv /Run does not work. There is also no way to start debugging without starting VS.

I hope that answers your question, though I'm still not clear on how you're trying to add PTVS into your workflow.
May 22, 2013 at 7:04 PM
There are also some COM Automation APIs available for VS, which cover various debugging features:

This may also be helpful:
May 24, 2013 at 1:34 PM
Thanks for the info. This is getting me closer.

I am now able to open the scripts into VS. I can execute the scripts using the interactive window and the results show up in our 3rd party tool. However, I'm not sure how to debug the scripts. It appears I have to attach to a process ( meaning, there is no Debug button like it would be if I had a project loaded ). This scripts are not located in a project, so do you know the steps in order to attach for debugging?

Thanks again.
May 24, 2013 at 6:17 PM
The COM Automation APIs will help you here. Once you get a DTE object (if you have the devenv.exe process ID you can do it this way) you can do pretty much anything.

We have a Debug as Script command that you can invoke with ExecuteCommand which will operate on the active file - the command name is DebugAsScript and you can find the full name through Tools->Customize->Keyboard. But bear in mind that we don't officially support this, so it may change and it may not be entirely reliable. (Though if you have feedback that could make it more reliable, let us know and we'll see what we can do.)

If you're attaching to a process that's already running, you'll want to start by looking at EnvDTE80.Debugger2.GetProcesses - we have port providers for scripts that are using our ptvsd package (look in Debugger.csproj... I assume you're looking at our source code? You should be) and we can use the default transport if we're attaching to a regular CPython process. This is a little more involved and not 100% reliable (I've been using it recently and there are some odd COM exceptions that require a short delay before retrying), but it works identically to having the user go through Debug->Attach to Process manually.
Oct 11, 2013 at 4:15 PM
I have not worked on my problem for some time, but trying to review and get working again. I have a few more questions....

First, it appears PyScripter can be opened (either by Start >.... or by command-line. A user can then open or create a new module and run/debug the file that is currently selected. Without needing a project.

1.) So is there way to open VS and open or create a file without a Python project and begin running/debugging?

2.) I was able to create a Python project and delete the original file added. This file would be called if I run/debug. Since I remove the file, I get a pop-up that states "No startup file is defined for the startup project". Is there a way to call into the my project and add the a startup file to the empty project via the command-line.
Oct 11, 2013 at 5:15 PM
Edited Oct 11, 2013 at 5:18 PM
Regarding #1, you can just open the file via File -> Open File to edit, and then right-click on its tab and select "Run as Script" or "Debug as Script". This will also respect breakpoints etc.

Regarding #2, I'm not quite sure what you mean by "call into". The way you normally set the startup file in VS is by right-clicking it in Solution Explorer and saying "Make startup file". If what you need is to modify the project file from your script that runs outside VS (and with VS generally completely outside the picture), then it should be fairly trivial as .pyproj files are just XML - an MSBuild script, to be precise - and startup file setting is an XML element (MSBuild property) in that script.

OTOH, if you want to tell VS to mark the file as a startup file, then this is exposed as a command, Project.SetasStartupFile - which will mark the currently selected file in Solution Explorer as startup file.
Marked as answer by shaggygi97 on 10/11/2013 at 10:33 AM
Oct 11, 2013 at 5:29 PM
In the latest releases, you'll see "Start with debugging" and "Start without debugging" in the context menu anywhere in the editor (including on its tab). We changed it from "Debug/Run as Script" because there was no point in using a different name for something that already existed.
Oct 11, 2013 at 6:19 PM
Thank you for the info. Your response to #1 was exactly what I needed. VS with PTVS is now working as needed similar to PyScripter when using this method.

Thanks again. I will close this out.
Nov 5, 2013 at 6:22 PM
Was there any changes of this feature in addition to changing the name from "Debug as Script" to "Start with debugging"? It appears this would work for me in VS 2012, but seems to lock up with VS 2013. The file will run when selecting "Start without debugging", but locks up with "Start with debugging".
Nov 5, 2013 at 6:33 PM
There were some other changes (we originally wrote a lot of duplicate infrastructure when adding Debug as Script, which was removed), but it's more likely that there's something in your script that is causing the lockup. That it works without debugging suggests that the debugger is the problem; you could verify this by adding the script to a project and using F5 (but after we merged it, the code is identical).

The most likely cause is something that you're importing, especially if it's throwing exceptions while being loaded. You can check this by enabling break on all exceptions immediately (the Throw checkbox shown here), which should interrupt you often, but could also show which module is causing the problem.

In the past, we've had packages like numpy cause deadlocks in the debugger between our own lock and CPython's import lock. Another possibility is that it is simply very slow to load under the debugger, again probably due to exceptions. If you can identify the problematic package, that would be very helpful.
Nov 5, 2013 at 6:47 PM
Thanks for the quick response. I checked the Python exceptions and ran again. It does appear to lock up when it reaches the line of code to import a third-party module we are using.... from <vendor module> import *.

This module is only provided as compiled files (.pyc) so we do not have access to view its content. The module and Python version we are using is 2.6 if that helps.

What would be the next steps?
Nov 5, 2013 at 9:05 PM
Edited Nov 6, 2013 at 4:54 PM
If you can't share the module with us (if you can, you can email to ) then you'll need to diagnose the deadlock in python.exe. We've had to do this a couple of times and it's not easy (especially in Python 2.6), so I can't recommend it lightly.

Best if you can get hold of their source and narrow down exactly what's causing the break, or can get us a repro that we can debug.