4 ms·
Activating the venv is completely optional. I never do it, but some people seem to like it.
by danmur 6y ago
Activating the venv is completely optional. I never do it, but some people seem to like it.
- user5994461 6y agoIt's not optional. It's required for things to work properly. A basic example of something that would break if the environment is not activated is binaries, like mypy. You have a script that calls "mypy"? Gotta be in the virtual environment to invoke it, otherwise the executable might not be found, or worse, it might run another executable.
- danmur 6y agoIt's absolutely not required, I assure you. If you run the Python binary inside the venv you have the same environment as if you'd activated the venv, but only for that execution and not affecting your shell. Try making a venv, running python, and looking at sys.path.
- user5994461 6y agoI assure you 100%, it is required for everything to work, it's not just here for the show. One of the thing that the virtual environment does is modify the PATH to lookup executables from the virtual environment first. This is to ensure that when a script calls binaries like mypy/python, it's going to find the same binary from the environment it's currently running in. Typically if the environment is not activated, python is going to lookup to /usr/bin/python and might be something else. This is most noticeable when there are different versions of python on the systems and when having scripts that invoke themselves.
- danmur 6y agoI see we will not agree, and this thread is mostly dead anyway, but for posterity: it sounds like you haven't installed mypy into the venv you're using. I can see how that would not work. I don't try and reference python scripts that I haven't installed using the venv so perhaps that's why I've never encountered this situation. If it's part of my project it's installed into the venv (and if it's a dev dependency like mypy, which I do use, it gets installed as a dev dependency so it doesn't end up in releases).