I generally recommend against `source ./bin/activate` for virtualenvs — it's convenient if you're using a single shell session interactively, but it plays quite

I generally recommend against `source ./bin/activate` for virtualenvs — it's convenient if you're using a single shell session interactively, but it plays quite poorly with the Unix process model of environment variables being inherited from parent processes to child processes. Instead, I recommend just running the other executables in the bin directory. `./bin/python` will drop you into a Python REPL with all the packages installed in that virtualenv available. Your IDE should let you specify what Python interpreter to use for running tests and other integrations; give it the path to that Python executable and everything should Just Work. Likewise, if your package uses setuptools entrypoints, they'll be installed into the bin directory too, and you can just run them with no further configuration. For what it's worth, Rust (for one) works pretty much the same way. The only difference is that Rust doesn't have a concept of dependencies installed system-wide, they're always handled per-project like venvs. As a result, they don't have decades of stale tutorials online telling people to do the wrong thing.