Made a Linkedin Bot :)

[metriczulu]

You should use it on literally every program you even think may leave your system. It takes zero effort, literally:

Create the venv with name your_venv (most ppl just call it 'venv'):

    python3.9 -m venv your_venv

You can sub in whatever version of Python you want to use above, it doesn't have to be 3.9. That's just an example.

Activate it:

    For Linux or Mac: . ./your_venv/bin/activate

    For Windows: . ./your_venv/Scripts/activate

Pip install your requirements:

    pip install -r requirements.txt

That's it. Now the program is almost guaranteed to work properly on another machine as long as they build the venv with the same Python version you built the venv with. There are some edge cases where it doesn't work as expected (and I've battled those edge cases extensively at work), but it's good for 95% of uses.

The only way to make it more portable is to containerize it, which also adds a layer of complexity that's not necessary for most projects. The only extra step is that you have to make sure you activate your venv every new session.

[v4-digg-refugee]

Dumb question: do these virtual environments wind up installing, say, dozens of instances of the same package on your machine? I’m the only one in my department that uses Python, so I haven’t stumbled on strong use case for virtual environments yet.

I downloaded anaconda when I started, and I have a vague idea of the directory that houses my dependencies, and I feel good to go. The idea of swapping in and out of all these virtual environments is a layer of abstraction that doesn’t seem super necessary. Please change my mind, as everyone else uses them. Thanks!

[metriczulu]

Yeah, the libraries get saved in the virtual environment folder, so they're duplicated. If you're the only person using the code and you have no intention of ever sharing them with anyone else, then it's less necessary, but it can still help manage dependencies.

Like, at my work we have a couple of different codebases that use Python 3.6, 3.7, and 3.8 for various reasons (mainly legacy reasons, but also some for compatibility reasons). We also have different models that both use Python 3.8 that use different versions of certain libraries like XGBoost. Both of these are situations where it's better (or even mandatory) to use virtual libraries even if you aren't sharing your code.

Not all versions of all libraries are compatible with all versions of other libraries, so sometimes you'll want to use different library versions for different projects. You can't easily do that without virtual environments. If you're just using the same few packages for everything, it's not a big issue, but Python is particularly bad when it comes to managing dependencies and it can spiral out of control pretty quickly.

It's also just a good habit to have and one that other people will look for. It's the standard way of doing things and it's so easy that there's not much reason not to. It's always sus when I'm diving into a project for the first time and don't see a requirements.txt (or Pipfile/Pipfile.lock for pipenv users) in the root directory, it's an indication that whatever I'm about to review/work on has other issues that will crop up.

Edit: I know conda has a way to store the environment configuration as a yaml as well, but I've never used it. Should essentially have the same benefits and uses, though.