Start with debugging, sys.path



I'm new to PTVS and the error is probably on me. But I can't figure it out.
My default environment is "IronPyton 2.7"

I've set the system environment variable:

The path is correct in "IronPython 2.7 Interactive":
>>> import sys
>>> sys.path
['D:\\source\\Scdb2Apps\\HeadsAdmin\\StarcounterUtils', 'D:\\source\\BuildFW\\tools\\CmdTools', 'D:\\source\\Scdb2Apps\\HeadsAdmin\\StarcounterUtils', 'C:\\Program Files (x86)\\IronPython 2.7\\Lib', 'C:\\Program Files (x86)\\IronPython 2.7\\DLLs', 'C:\\Program Files (x86)\\IronPython 2.7', 'C:\\Program Files (x86)\\IronPython 2.7\\lib\\site-packages']
But when I start my script from within the same VS instance using "Start with debugging" sys.path misses my IRONPYTHONPATH and my module is not found:
['D:\\source\\Scdb2Apps\\HeadsAdmin\\StarcounterUtils', 'C:\\Program Files (x86)
\\IronPython 2.7\\Lib', 'C:\\Program Files (x86)\\IronPython 2.7\\DLLs', 'C:\\Pr
ogram Files (x86)\\IronPython 2.7', 'C:\\Program Files (x86)\\IronPython 2.7\\li
Traceback (most recent call last):
  File "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensio
ns\Microsoft\Python Tools for Visual Studio\2.0\visualstudio_py_util.py", line 7
6, in exec_file
    exec(code_obj, global_variables)
  File "D:\source\Scdb2Apps\HeadsAdmin\StarcounterUtils\NewImages.py", line 9, i
n <module>
    import scdb2create
ImportError: No module named scdb2create
Best Regards


careri wrote Oct 16, 2013 at 9:40 AM

It seems that IRONPYTHONPATH is not set when Start With Debugger is used:
print os.environ['IRONPYTHONPATH']
In Interactive:
>>> os.environ['IRONPYTHONPATH']

Zooba wrote Oct 16, 2013 at 3:41 PM

That's correct. You may not like it, but the bug here is that we're using IRONPYTHONPATH in the interactive window (not that we're ignoring it elsewhere).

This is usually a surprise to people, but it comes down to our support for multiple versions of Python, that CPython uses PYTHONPATH for every single version, and that (on Windows) this is often set globally, as you have done. What this means is that you can't reliably set PYTHONPATH and use CPython 2.7 and 3.3 on the same machine (we generalise this for different interpreters - we always reset the value, whether multiple versions of the interpreter exist or not - because that way it is more consistent).

The 'fix' for your project is to add the path to Search Paths in Solution Explorer. There is a feature request open that would let you create a custom interpreter and set the value (at the moment we only let you set the name, which is going to be PYTHONPATH/IRONPYTHPATH/etc.). This will also let us provide IntelliSense in the editor for the files in that path - something we don't do with the system-wide variable.

So the error isn't on you, but on us for not clearly explaining why we ignore the global value. (This is not the first time I've had to explain it this week... we're going to do something about it :) )

Zooba wrote Oct 16, 2013 at 6:50 PM

I've added a documentation section at https://pytools.codeplex.com/wikipage?title=Features%20Projects#search-paths. Let me know if you have any suggestions that can help make it clearer.

careri wrote Oct 17, 2013 at 11:51 AM

Ok, that explains it. The thing is that I'm using a single python script in a solution directory, the script is used for cleaning up some resources. Meaning that I don't actually have a python project to configure the search paths for.

I solved it by altering the Sys.Path from the script. I'll look into adding a python project to host the script.


careri wrote Oct 18, 2013 at 8:32 AM

What do you think of this idea?
What about using the global environment variable for the current interpreter if the python script being executed doesn't have a Python project as parent?

Zooba wrote Jan 20 at 5:24 PM

(Sorry for the long delay in responding.)

I'm not entirely convinced by that idea either, to be honest. All the existing problems will still be there, but there is no workaround.

Our next version will have a menu item to add the current PYTHONPATH (or equivalent) value to search paths, and will also clear the variable in the interactive. What we're planning to add (eventually... only maybe in the next release) is a way to set search paths for an interpreter, so you can set the value as well as the name. In this case we'll probably try and pick up the global value by default (or at least make it easy), since there will be a way to override it. (Making this work nicely and intuitively, including when you install something that modifies the global PYTHONPATH after you've already configured it in PTVS, is why we don't want to rush it.)