Visual studio: Python virtual environments in source control

Question

I've managed to succesfully setup a Visual Studio Python project. I now want to share this project with other developers through source control (the company I work at uses SVN).

As I want to avoid each of my colleagues having to manually setup the same Python environment, I looked into using a Virtual Environment. In my head, this seems very similar as to how NPM modules are stored locally.

Without too much hassle, I managed to setup a Virtual Environment, which works brilliantly.

However, I was ready to exclude my "Virtual Environment"-folder from being checked into SVN, when I noticed that the "pyproj"-file contains a reference to my local virtual environment:

<ItemGroup>
  <Interpreter Include="VirtualEnvironment\">
  <Id>VirtualEnvironment</Id>
  <Version>3.6</Version>
  <Description>VirtualEnvironment (Python 3.6 (64-bit))</Description>
  <InterpreterPath>Scripts\python.exe</InterpreterPath>
  <WindowsInterpreterPath>Scripts\pythonw.exe</WindowsInterpreterPath>
  <PathEnvironmentVariable>PYTHONPATH</PathEnvironmentVariable>
  <Architecture>X64</Architecture>
</Interpreter>

If I remove the "Virtual Environment"-folder and open the Visual Studio solution, I don't have any option to restore the environment based on the generated "requirements.txt"-file (as I expected). Unless I remove the non-working "Virtual Environment" and add a completely new one.

This leads me to believe that there is something wrong in my work-flow or assumptions.

• Should I not exclude the virtual environment from being checked-in?
• Should I only exclude parts of the virtual environment and if so, which parts?

Side notes:

• As you can probably tell, I'm still fairly new to using Python, so any advice is very welcome.
• The reason I want to use Visual Studio is because the company is primarily .NET focused, which makes it a very farmiliar environment for most developers.
• I did read Working with python in Visual Studio - Step 06 Working with Git, but it doesn't mention Virtual Environments at all.

Answer 1

After posting an issue on the MicrosoftDocs GitHub, I received the following reply from zooba:

There's certainly some work in progress around this area. We're looking at different designs here and ways to better align VS and VS Code.

For Visual Studio: the intent for virtual environments in a Python project file is that you have the environment within your project directory, so it is only referenced by a relative path. If you also keep a requirements.txt file in your project, it should only be a couple of clicks to recreate it on a new machine (we had considered automatic prompts to help out here, but most user feedback indicated we had other stuff to fix first).

So our broad recommendations would be:

• have the "main" virtual environment be at the default location (env in the project folder)
• exclude the entire environment itself from version control
• keep development requirements in a requirements.txt file
• recreate the virtual environment on new machines with the normal Add Virtual Environment command (having the default location and requirements file will make this smoothest - we'll change it from "missing" to found as soon as it's created)

Obviously feel free to vary these as they make sense. You can also have a different task create the virtual environment (e.g. a batch file that runs python -m venv path\to\env) and we'll still pick it up just fine without having to modify the project file.

And as we work on improvements here for the overall process, it should get easier to just have an environment "somewhere" and use it, rather than having to make specific configuration settings in your project.

Answer 2

IMHO: the best way to do is to have a requirements.txt, and write how to install python env. in readme.txt.

What you will check-in is requirements.txt and the readme.