I'll take a chance to plug `vrun` https://pypi.org/project/vrun/ here as well which is a very lightweight wrapper around activate that only applies to the current command. You can use it to start a subshell if you wish.
The fundamental problem is that virtualenv scripts are not actually bound to their actual virtualenv. If you forget to activate and a script shells out in a subprocess to execute another script it will not find the version installed into the virtualenv. This should be fixed upstream but so far it doesn't look like it is.
$ python3 -m venv env
$ env/bin/pip install vrun
$ env/bin/pip install foo # assume foo depends on bar and tries to start bar via subprocess
$ env/bin/foo # fails because bar is not on the path
$ env/bin/vrun foo # works
`foo` is now executed in a process in which the virtualenv is fully activated and will find appropriate dependencies on the path if it tries to run a subprocess, etc.
The fundamental problem is that virtualenv scripts are not actually bound to their actual virtualenv. If you forget to activate and a script shells out in a subprocess to execute another script it will not find the version installed into the virtualenv. This should be fixed upstream but so far it doesn't look like it is.
`foo` is now executed in a process in which the virtualenv is fully activated and will find appropriate dependencies on the path if it tries to run a subprocess, etc.