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

Custom IronPython Install - Intellisense can't find clr module

May 2, 2014 at 9:47 PM
As the title says, when I use a custom installed IronPython directory (not the installed MSI), intellisense can't find the clr module. I encountered this in a non-clean machine, so I fired up a fresh VM and did the following on a Windows 8.1 VM. All default directories:

Installed Visual Studio 2013
Installed Python 2.7 (C:\Python27)
Installed IronPython 2.7 from the MSI
Installed (Copied) IronPython to a custom directory from the .zip file, C:\CustomDir\IronPython

Installed all updates and such, so I'm on "the most recent" that's not beta.

So I make a new project, iPyConsoleTest, an IronPython Console Application. I ensure that the default environment is "IronPython 64-bit 2.7" and have done "Refresh DB" on it. The default script has this:
print('Hello World')
I type "import " and clr comes up in the intellisense. Fine. And I import it, and then do "clr." and again, intellisense is working for the module members.

So then I add a new environment through Tools->Options->Python Tools->Environment Options menu. I click "Add Environment" and name it "Custom IronPython". And I fill in the following:
  • Path: C:\CustomDir\IronPython\ipy64.exe
  • Windows Path: C:\CustomDir\IronPython\ipyw64.exe
  • Library Path: C:\CustomDir\IronPython\Lib
  • Architecture: x64
  • Language Version: 2.7
  • Path Environment Variable: IRONPYTHONPATH
Note that the IRONPYTHONPATH environment variable does not exist on this machine, and these settings, except for the directories, are identical to the "detected" settings for the "IronPython 64-bit 2.7" profile. I made sure to click "Refresh DB" for it and it appeared successful.

So then I change the project "Python Environments" to have ONLY "Custom IronPython" in it, and delete the last two lines, and try "import " and clr isn't found. I do "clr." and there is no intellisense at all for it. I can run it and it succeeds, but intellisense is completely blind.

So what's the deal? Detected environments can see "clr" and such, but if you point it at a directory, it can't? Or does the installer package have things that aren't in the .zip from the website? Or is there some other setting I should be doing to ensure that my .zip install dir for IronPython works?

Bonus: If you bring up the interactive environment, "import" doesn't find CLR for intellisense, but once it succeeds, intellisense DOES work for the clr members on the next interactive line.
May 2, 2014 at 10:31 PM
It's actually really simple (and I think I'll even get the bonus points :) ):

When we detect an IronPython interpreter, we represent it as an IronPythonInterpreterFactory object.

When you configure one, we represent it as a ConfigurablePythonInterpreterFactory, which is based on the CPython one.

These two factories produce different internal objects - one of which has the .NET support and the other doesn't. So we treat the configured environment like CPython, mainly because we don't even look to see what it actually is.

One of the first feature requests I ever made for this project (it's our second oldest issue that is still open) was to handle this situation. It never got enough traction for us to go off and implement it.

If you have your custom interpreter on your PATH variable and don't have an installed version, then we should detect yours. Unfortunately, I don't have a better solution that doesn't involve a custom build of PTVS (well, only really our IronPython extension package - this is mostly isolated from the rest of the code). There's a bit of work to do at a minimum to support multiple versions of IronPython at once, as we currently only show one (it looks like two if you have the 64-bit version, but internally it's just one).

For the bonus points: in the interactive window we run the interpreter hidden and ask it what we should display (which may execute arbitrary code, hence we don't do it in the editor). On the first line, you get the same as what's in the editor, but after that you'll get whatever IronPython reports. If you run any command first to get it started (print 'Hi' will do) then you'll see clr in the list of modules after that.
Marked as answer by EriolAncalagon on 5/2/2014 at 3:22 PM
May 2, 2014 at 10:46 PM
(Minor, irrelevant, correction. We don't have the ConfigurablePythonInterpreterFactory class any more - it was so close to being identical to the CPython one that I merged them a while ago. We still have a separate provider for it.

This only matters if someone reads this and then goes looking at our code.)
May 2, 2014 at 11:28 PM
You get the bonus points. ;)

I hope it DOES get enough traction soon. I'm definitely not a fan of "magic" behind the scenes so that certain environments get what we want, and others don't, with no indication to the user that they're different. If I had to specify in the Environment configuration IronPython as a flag/enumeration, that'd be fine too. Then you can have it work against beta install directories, multiple of the same (or compiled), etc. It just seems odd that any custom environment is always CPython. Defaults I'm OK with, but not letting us set it at all? Ouch.

But if it doesn't work with a custom install dir (where we install our product), I have somewhere near-zero possibility of getting this into my current work environment. And we'll be stuck with what we're using now for scripting (don't ask, it's internal & custom and horrible). Whereas if I prove that IronPython will work with Visual Studio flawlessly, then I might get us to switch, or at least side-by-side support.

Save me from custom scripting engines. Please!
May 2, 2014 at 11:51 PM
If you know it'll be the only IronPython installed in your environment, go ahead and set HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IronPython\2.7\InstallPath (the (default) value is like C:\Program Files (x86)\IronPython 2.7\). Then we'll pick it up automatically and it will work just like the official install.

One thing counting against it is that from our point of view, it looks like "nobody" is using IronPython. We have very few examples of businesses or products that rely on it, and so every time we get to prioritise features, most things to do with IronPython are lower than CPython (Jython and PyPy are even lower... :( ).

If you wanted to email us privately and describe in more detail how you're relying on IronPython, you can email No promises, but more data helps us make better decisions.
It just seems odd that any custom environment is always CPython
They're not actually CPython, they're a "generic Python environment that happens to be identical to CPython". I know that isn't helpful, but it seems less odd when you consider that IronPython is the special one. :)