> An example:

None of this example has anything to do with performance or reliance on C dependencies, but ok.

> even now it makes 0 sense to me why virtual envs are not designed and supposed to be portable between machines with the same architecture (!).

They aren't designed to be relocatable at all - and that's the only actual stumbling block to it. (They may even contain activation scripts for other platforms!)

That's because a bunch of stuff in there specifies absolute paths. In particular, installers (Pip, at least) will generate wrapper scripts that specify absolute paths. This is so that you can copy them out of the environment and have them work. Yes, people really do use that workflow (especially on Windows, where symlinking isn't straightforward).

It absolutely could be made to work - probably fairly easily, and there have been calls to sacrifice that workflow to make it work. It's also entirely possible to do a bit of surgery on a relocated venv and make it work again. I've done it a few times.

The third-party `virtualenv` also offers some support for this. Their documentation says there are some issues with this. I'm pretty sure they're mainly talking about that wrapper-script-copying use case.

> Or why venvs need to be activated with shell-variety specific code.

The activation sets environment variables for the current shell. That isn't possible (at least in a cross-platform way) from Python since the Python process would be a child of that shell. (This is also why you have to e.g. use `source` explicitly to run the Linux versions.)

But venvs generally don't need to be activated at all. The only things the activation script effectively does:

* Set the path environment variable so that the virtual environment's Python (or symlink thereto) will be found first.

* Put some fancy stuff in the prompt so that you can feel like you're "in" the virtual environment (a luxury, not at all required).

* Set `VIRTUAL_ENV`, which some Python code might care about (but they could equally well check things like `sys.executable`)

* Unset (and remember) `PYTHONHOME` (which is a hack that hardly anyone has a good use case for anyway)

* (on some systems that don't have a separate explicit deactivate script) set up the means to undo all those changes

The actually important thing is the path variable change, and even then you don't need that unless the code is going to e.g. start a Python subprocess and ask the system to find Python. (Or, much more commonly, because you have a `#!/usr/bin/env python` shebang somewhere.) You can just run the virtual environment's Python directly.

In particular, you don't have to activate the virtual environment in order to use its wrapper scripts, as long as you can find them. And, in fact, Pipx depends on this.