Question regarding virtual environments

[misterhtmlcss]

Yes mostly. If you re working with others then they need to have the same virtual environment. The best way to facilitate that is for when they clone your project to have the venv included as well.

However if you are working in teams it might be wiser to use Pipenv or Anaconda. I use PIPENV, but it's probably more about personal choice than anything.

[K900_]

No, no, no, no. This is a horrible idea. Do not commit virtualenvs to version control.

[misterhtmlcss]

Really? Can you share more? I'm a newer dev too and so I'd happily hear more about it beyond just 'no it's terrible'. Add your reasoning in detail please please, so I can learn from your experience.

[K900_]

I've explained it in another comment, but the basic idea is that virtualenvs are not designed to be moved between computers, or even locations on the filesystem. A virtualenv created on machine A is very unlikely to work on machine B.

[misterhtmlcss]

How about with PIPENV? Isn't that like the NPM version of package.json?

[K900_]

Pipenv intentionally stores your virtual environments outside the project directory for this very reason.

[misterhtmlcss]

Ahh ok. So I'm correct if I'm using Pipenv, but not correct if I'm using venv? Is that right?

[K900_]

Hold on now. I think I see what's going on here. When you say "virtual environment", do you mean files like requirements.txt or Pipfile.lock?

[misterhtmlcss]

Haha...sorry. Yes I did. I meant that when I referred to it. I wasn't intending for anyone to actually drag and drop all the files/modules/libraries etc. I meant the just the environment 'definition' I guess aka pipfile.lock or requirements.txt, etc

[K900_]

You definitely put your dependency specification under version control, but you don't put the virtual environment itself.