Hacker News new | past | comments | ask | show | jobs | submit login

He also said virtual envs install their own copy of Python. No need for that either. Coming from other languages the whole virtual env thing seems alien especially the way it messes with your shell.



A virtualenv (venv) does not install its own copy of Python. Instead, when you create the venv it puts symlinks for the calling python in the <venv>/bin directory. When you activate the venv the <venv>/bin is added to the front of your PATH so that any "python" commands use the symlink'ed version of Python corresponding to your venv.


Indeed, a virtual env is really not that exciting or complicated. Even "activating" a virtualenv is just changing your shell's PATH so it picks the virtualenv binaries, nothing else. You can also just call those binaries directly from their installed location in the env without ever having to "activate" or "workon" anything.


Activating the venv is completely optional. I never do it, but some people seem to like it.


It'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.


It'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.


I 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.


I 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).


Do you not use nvm or something similar then? That "messes with your shell" in exactly the same way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: