> [complex commands to set up a venv follows]
"All you have to do is... recompile your kernel... check your version dependencies... maybe do that once or twice. It's so simple, I don't know why everyone doesn't do it!"
Ubergeek.tv's classic "Switch to Linux" spoof ad of 2001:
python -m venv myvenv
myvenv/bin/pip install ...
Compared to "just pip" it's one whole extra line, so I don't think it's amazingly godawful at all.
For newbies, writing one line is impossible.
Which the author explicitly said does not exist for the use case he is discussing:
"the environment our Python program runs in doesn't really have a home directory"
You can certainly put a directory wherever you like and put the code there. In fact, that's exactly what the author did, as he describes in the article.
What you can't do is just magically have that directory be the "home" directory of a user and have the $HOME environment variable always point to it. You might be able to set things up to do that in principle, but it might not be worth the trouble as compared to other solutions. In fact, that's pretty much the position the author takes in the article for his use case.
$HOME or not is a red herring, i apologize if it appears more salient than it really was meant to be.
No, it's "I don't need the full power of venv so I'll just put the code in a specific directory now that I've figured out how to tell pip to do that when it's not a user's home directory". Using pip install's "--target" option hardly qualifies as a "terrible hack". The designers put it there because there were valid use cases for it. Setting environment variables before running a program is hardly a "terrible hack" either; it's one of the most common uses for shell scripts.
> $HOME or not is a red herring
If all you meant by it is "put the code in any directory you like", then, as I said, that's exactly what the author did.
Most Python developers have virtualenv creation done for them via their IDE or scripts that vastly simplify the process so that you don't need to bother with the details in the OP.
development != deployment.
The whole point of a container is to isolate dependencies.
The whole point of a virtualenv is also to isolate dependencies.
If using a container, why bother with a virtualenv at all?