Store project-relative interpreter path

> PyCharm stores the interpreter name with the project, but not the interpreter path

Is it possible to store the path?  Specifically a project-relative path?  I have a script in my project that sets up a virtualenv for that particular copy of the project and would like to use that particular relative path.  Of course, Windows vs. Linux relative paths vary (silly virtualenv?) but even a single platform solution would make me happy for the moment.

Thanks for any suggestions.


You are right, the project stores a reference to the defined interpreter. PyCharm's workflow presumes you want interpreters/virtualenvs managed separately from the project. I've lately been thinking differently about that and would like to open a conversation about how this could change in the future.

Your sentence about "I have a script..." goes in the direction I've been thinking. I'd be interested to hear more about what you'd like, in a perfect world.


I personally think there is a place for both approaches.  Anyways, my virtualenv setup script is available on GitHub.

Once I wrote it up I found references to virtualenv bootstrapping features but never got back to look at them.  Anyways, it checks for a couple dependencies I expect the user to install and notifies them how too and automatically downloads the rest and installs them into the virtualenv.  It also adds a bit to the activation stuff to help with launching Qt Creator with the right settings for my project.

Also, I looked back and realized I had forgotten about having had what I wanted at least sort of working before.

I'm not sure which pieces are most important but that seems to maybe be working for Linux in at least my first re-checkout and open in PyCharm.

What would I like in a perfect world? Hmm...  My overall point is to have something that self configures and minimizes user intervention to get up and developing.  Checkout the repo, run my script, open the project in PyCharm, launch the application.  In this particular context that would mean:

  • Use virtualenv with path that may be relative to project (simply via `$PROJECT_DIR$` is fine)
  • Account for variations (two paths? virtualenv layout awareness?) in virtualenv between Linux (`bin/python3.4`) and Windows (`Scripts\python.exe`) (and OSX?)

So, I may have just asked the question too soon but perhaps it was good anyways in case you find anything useful in what I've shared above.  Let me know what you think of this use of the configuration.  I'll let you know if I find issues with it in my use (beyond only supporting Linux or Windows).

Thanks for your interest.


First issue found.  While I can launch it in regular run mode, debug reports "No Python interpreter configured for the project".

I would also add to my list of wants:

  • Easy setup in the GUI for the relative path

+1 on the idea of being able to specify values in the config with something like $PROJECT_DIR

I have a project which setups a virtualenv directory in the project folder that is shared into a vagrant instance, so the interprepter path never changes relative to the project file.

When my developers check out the project, there are always 1-2 version controlled pycharm files in .idea which (automatically) get changed based on the actual full path they checked the file out.

One example in .idea/misc.xml

<component name="ProjectRootManager" version="2" project-jdk-name="Remote Python 3.4.3 Vagrant VM at C:/projects/rams/prime-deploy/ubersystem-deploy (/home/vagrant/uber/sideboard/env/bin/python3)" project-jdk-type="Python SDK" />

Another in .idea/{projectname}.iml:

<orderEntry type="jdk" jdkName="Remote Python 3.4.3 Vagrant VM at C:/projects/rams/prime-deploy/ubersystem-deploy (/home/vagrant/uber/sideboard/env/bin/python3)" jdkType="Python SDK" />

If those could use $PROJECT_DIR, then those files would not have text modifications when the IDE starts up.


unrelated, part of my setup instructions involve adding a vagrant interpreter to the project on first time setup.  It would be great if PyCharm just remembered the vagrant settings that are checked into source control and it all just worked without having to have the developer set it up each time.

i.e. I'd like it if all the vagrant stuff in the setup instructions here was not necessary:    It shouldn't be needed because the project always puts the interpreter in the same project-relative place each time, so why should the developer have to manually add this?


If you need more info just hit me up.  PyCharm is great and these are ultimately kind of minor annoyances for these kind of centrally managed workflows, but would be great to see them fixed up :)


Even in Linux where my hard-coded `<option name="SDK_HOME" value="$PROJECT_DIR$/venv/bin/python3" />` (in `.idea/runConfigurations/<...>.xml` works for launching the scripts, I still don't have a project interpreter so I lose lots of the quick navigation features to definitions in the libraries I have installed as source.

I really wonder what everyone else does.  Just have a shared virtualenv for all development?  Hmm...


For reference for future jetbrains folks working on this, here's a copy of our setup procedures for our install:

One developer might have 2-3 installs alongside each other, activated one at a time.

For each install, our deployment scripts creates a linux VM and sets up the virtualenv inside it. Then you run pycharm on the host OS (like windows).

Despite the python interpreter being present in a path relative to something like $PROJECT_DIR, the developer still has to tell pycharm where the interpreter is each time.  This sucks just because for us, it's an unchanging thing and one more thing that the developer has to remember to do correctly.  It would be awesome if the first time they opened the pycharm project after a deploy, pycharm was able to remember (as part of the .idea folder contents) that the interpreter was in a particular subdirectory (which is always is going to be consistently in the same spot).


DOM C, it's funny, just as you sent this, I was asked to review the comments on this article about project settings.


Gotcha, nice :)    I figured from poking around in the .idea folder that there likely needs to be some reorganization in there for project-specific vs user settings, seems like a bit of a tough thing to untangle with lots of backwards compatible stuff going on.  Good luck though and happy hunting!



This is a needed feature, if you work on a lot of projects the interpreters list ends up being a mess. This is mine:

My normal workflow is to clone a repo, create a virtualenv in a 'venv' folder on the same location then create a new project with PyCharm, and a new interpreter as this virtual environment is for the only purpose to use in that project.

PyCharm treat all the python interpreters as available for all projects. Where this is a sane assumption with Java envs in IntelliJ is simply not correct for Python virtual environments, all the venvs above are for the only purpose to be used only on it's own projects, never to be reused.

For a possible implementation a new 'Add Relative' could be added, with the 'Add Local', 'Add Remote' on Create Interpreter menu, that store all the inspections cache and all of that PyCharm interpreter related files inside of the '.idea' project folder.

I work time ago with RubyMine but i don't remember how it deals with all the local Bundler installations, perhaps is a good place to look for something similar.



I would like to push for this as well. In my few years of experience with python, normally each project will need its own venv. The reason is the dependencies for the project goes into the venv. This is unlike Java, where the JDK is basically a readonly interpreter and dependencies goes elsewhere. For this reason it would be extremely helpful if there was an easy way to specify a python interpreter relative to the project.

If this is for whatever reason not feasable, at least make it so that I can configure my venv without causing changes to checked in files.


we used to distribute projects with the project.iml using 

<orderEntry type="inheritedJdk" />

and it would just inherit from the system default python interpreter... this is no longer working for us and folks have to always set the interpreter manually... 



For anyone that hasn't found it, there's also an issue reported that would be related to this.


7 years later, and there is still no way to have interpreters that are relative to the project!?????

There is an existing feature request on this matter:
Please vote for it to raise its relevance and receive updates regarding its status.

Please sign in to leave a comment.