2

I am working on a Python project on both my work computer and my home computer. GitHub has made the experience pretty seamless.

But I'm having a problem with the pyvenv.cfg file in my venv folder. Because my Python SDK has a different file path on my work computer compared to my home computer, I have to manually go into pyvenv.cfg to change the home = C:\Users\myName\... filepath each time I pull the updated version of my project from my other computer, or else the interpreter doesn't work.

Does anyone know a solution to this problem?

bad_coder
  • 11,289
  • 20
  • 44
  • 72
pretend-engineer
  • 33
  • 1
  • 4
  • It sounds like you've added the virtual environment folder to your project and included it in the files that you put on GitHub - is that assumption correct? (if so, that's not the way to do it, but happy to explain how to resolve in an actual answer) – Grismar Jan 04 '21 at 06:07
  • Hi Grismar, that's correct - I included my entire project folder in my repository on Github (including the virtual environment folder). This is my first project with Python and I'm also relatively new to Github as well. Would love any advice on how to do this properly (everything works fine so long as I manually change the filepath in 'pyvenv.cfg' each time I pull from different computers). – pretend-engineer Jan 04 '21 at 06:10
  • As more background info, I learned about my workaround solution here (pch's answer): https://stackoverflow.com/questions/52404529/cannot-setup-a-python-sdk-in-pycharm-project-using-virtualenv-after-os-reinsta – pretend-engineer Jan 04 '21 at 06:13

2 Answers2

3

You shouldn't keep the full virtualenv in source control, since more often than not it's much larger than your code, and there may be platform-and-interpreter-version specific bits and bobs in there.

Instead, you should save the packages required -- the tried and tested way is a requirements.txt file (but there are plenty of alternatives such as Pyenv, Poetry, Dephell, ...) -- and recreate the virtualenv on each machine you need to run the project on.

To save a requirements file for a pre-existing project, you can

pip freeze > requirements.txt

when the virtualenv is active.

Then, you can use

pip install -r requirements.txt

to install exactly those packages.

In general, I like to use pip-tools, so I only manage a requirements.in file with package requirement names, and the pip-compile utility then locks those requirements with exact versions into requirements.txt.

AKX
  • 152,115
  • 15
  • 115
  • 172
3

As confirmed in the comments, you've added the virtual environment folder to your project and included it in the files that you put on GitHub.

That's generally a bad idea, since it defeats part of the purpose of having a virtual environment in the first place. Your virtual environment will contain packages specific to the platform and configuration of the machine it is on - you could be developing on Linux on one machine and Windows on another and you'd have bigger problems than just one line in a configuration file.

What you should do:

  • create a virtual environment in a folder outside your project / source folder.
  • assuming you're using pip, you can run pip freeze > requirements.txt to create a requirements.txt folder which you can then use on the other system with pip install -r requirements.txt to recreate the exact same virtual environment.

All you have to do is keep that requirements.txt up to date and update the virtual environments on either computer whenever it changes, instead of pulling it through GitHub.

In more detail, a simple example (for Windows, very similar for Linux):

  • create a project folder, e.g. C:\projects\my_project
  • create a virtual environment for the project, e.g. python -m venv C:\projects\venv\my_project
  • activate the environment, i.e. C:\projects\venv\my_project\Scripts\activate.bat
  • install packages, e.g. pip install numpy
  • save what packages were installed to a file in C:\projects\my_project, called requirements.txt with pip freeze > requirements.txt
  • store the project in a Git repo, including that file
  • on another development machine, clone or pull the project, e.g. git clone https://github.com/my_project D:\workwork\projects\my_project
  • on that machine, create a new virtual environment, e.g. python -m venv D:\workwork\venv\my_project
  • activate the environment, i.e. D:\workwork\venv\my_project\Scripts\activate.bat
  • install the packages that are required with pip install -r D:\workwork\projects\my_project\requirements.txt

Since you say you're using PyCharm, it's a lot easier still, just make sure that the environment created by PyCharm sits outside your project folder. I like to keep all my virtual environments in one folder, with venv-names that match the project names.

You can still create a requirements.txt in your project and when you pull the project to another PC with PyCharm, just do the same: create a venv outside the project folder. PyCharm will recognise that it's missing packages from the requirements file and offer to install them for you.

Grismar
  • 27,561
  • 4
  • 31
  • 54
  • Noticing that people are still finding this response, today I would recommend using `virtualenv` in favour of using `python -m venv` in most cases; both work, but `virtualenv` has some features that you may like or need later https://virtualenv.pypa.io/en/latest/ and I think it's the most commonly used tool to create and manage virtual environments for Python; IDEs like PyCharm integrate virtualenv for their virtual environment management and creation by default (although they support others of course) – Grismar Jan 24 '22 at 22:17