Default interpreter paths for virtual environments


I'm creating a virtual environment (venv) on a network location (X drive) in order to allow other people to work on my project. The intention is for this project to be worked on by different people at different times (not concurrently) on their own computer. All data and scripts will be stored on the network drive, so I figured it makes sense to have the venv there too.

I can create the venv fine by going to Settings->Project Interpreter->(cog wheel)->Add... I use as my base interperter the python3 installation I have on my C drive (C:\Users\my_name\AppData\Local\Programs\Python\Python37\python.exe). The venv is made and everything works fine on my machine.

However, when I investigate the Interpreter Paths for the interpreter that's in my new venv(my_env\Scripts\python.exe), there are three paths that direct to my C drive. I'm confused as to why they are there, because I thought everything should be pointing to the new virtual environment folder I made on the X drive:

Furthermore, when a colleague of mine opens the project, I get a warning to configure the interpreter. When I configure the project from his machine to use the python.exe file in the new virtual environment I made, I get the following warning:

Which is particularly strange to me considering I set up the virtual environment using Python 3, but for some reason, on his computer, it's being read as Python 2.

Can someone please give me some guidance on the following things:

1) Why are there paths pointing to my C Drive after I make a venv on the X drive?

2) Why can't I get pycharm to use the interpreter on the venv on my colleague's machine?

3) Am I using virtual environments in the way they're intended, or am I naive to think a venv on the X drive should be self-contained (i.e. wouldn't reference anything on a local machine)?

Thanks in advance!

Comment actions Permalink

Hi Mark,

venv on a network drive, shared among multiple users, is certainly not a common scenario, and I highly doubt PyCharm supports that. In general, we do not recommend storing anything project related on a network drives, as it may cause performance issues, at the very least.

There are other ways to enable multiple developers working on one project:

1. Version control systems (PyCharm have built-in support of them).

2. Remote SSH interpreter - multiple developers can configure the same remote SSH interpreter, and execute their code on the same server in same environment, but it only supports global environment.

3. Docker - you can build a docker image with development environment, and share it for your team.

Comment actions Permalink

Thanks Andrey, I'll look into those other options.

Comment actions Permalink

Alternatively, I've heard of having some kind of script or configuration file that contains a list of packages and versions that can be run to set up an environment before any scripts within a project are run. I haven't looked into it too much yet, but if this rings a bell for anyone and they can point me in the direction of where to look, I'd be very much obliged.

Comment actions Permalink

There are multiple things that fall under that description:

- pip's requirements file (this is the simpliest way):

- pipenv's requirements file (Pipfile):


And yeah, those will also work. It means each developer will have a copy of his environment installed separately, but the packages/versions will be maintained according to the requirements file.

Comment actions Permalink

"It means each developer will have a copy of his environment installed separately, but the packages/versions will be maintained according to the requirements file."

This is more my intent. I'll look into these and will see about implementing them. Thanks!


Please sign in to leave a comment.