Are your users mostly working in projects/editor or using the Interactive windows?
Unfortunately, we 'fixed' that issue but didn't leave any way to somehow retain the same behavior.
One solution that would work for both is using a *.pth file in the Python install - all directories listed in
(or whatever the path is for you) are added to
, just like PYTHONPATH. You can create one of these files and overwrite it whenever you like. Python will handle it the same as PYTHONPATH (and hence our interactive window will work), and when we refresh the completion DB for the editor
we will also scan those directories.
Something else to consider is installing multiple versions into site-packages under different names, then use an
import ... as
statement (for example, having
and then doing
import mymodule1 as mymodule
). You could also make multiple copies of the Python interpreter and set up
to refer to them - this may add some training requirement but would save having to launch VS using a script. (Virtual environments are probably not a good solution since we require a project to use them, but that depends on how your
users are using PTVS.)
I'm afraid there's not much more I can offer. I can go into more specifics about anything I've suggested, especially if you can give me an idea of how PTVS is being used, and we're certainly open to making changes to PTVS 2.1 to improve this scenario.
1: System-wide values of PYTHONPATH cause more problem than they solve, especially when people have multiple interpreters installed. Yours is the first genuine use case we've heard where keeping the value makes sense - most people don't set environment variables
before running VS.