[hal9000-tng]

> No! The obvious and simple pip invocation is as follows:

> [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:

https://www.youtube.com/watch?v=Xtah_05BOe8

[hprotagonist]

I generalized a bit for completeness and to emphasize that contrary to the article's point, you can do all of this in $HOME and never install anything outside your home directory, which was a concern of the author as a usage policy for their server.

  python -m venv myvenv
  myvenv/bin/pip install ...

works just as well, i just needed a concrete path to talk about in the rest of the text.

Compared to "just pip" it's one whole extra line, so I don't think it's amazingly godawful at all.

[mumblerino]

After we come up with that “one line”, we tend to forget how long it took us to get there.

For newbies, writing one line is impossible.

[pdonis]

> you can do all of this in $HOME

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"

[hprotagonist]

so put it wherever! it's just a directory, put it where you have write access.

[pdonis]

> so put it wherever! it's just a 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.

[hprotagonist]

the position the author takes is "i've never heard of `venv` so i'll do these other terrible 5 hacks instead".

$HOME or not is a red herring, i apologize if it appears more salient than it really was meant to be.

[pdonis]

> the position the author takes is "i've never heard of `venv` so i'll do these other terrible 5 hacks instead".

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.

[heavyset_go]

Using virtualenvs is standard practice when developing with Python. What the OP did will work with every standard Python installation out there.

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.

[hal9000-tng]

> .. standard practice .. when developing with Python

development != deployment.

[heavyset_go]

They're standard for deployment, too.

[alexchamberlain]

You really don’t want to do that... they can break silently when the system updates Python. Use safe system wide installation for deployment, such as docker or traditional system packages. Alternatively, you can look at one of the many bunglers/static linkers like PyInstaller.

[heavyset_go]

Ideally you'd deploy to a virtualenv in a container, recreating the virtualenv with each new image. You wouldn't update the system Python at all.

[hal9000-tng]

> Ideally you'd deploy to a virtualenv in a container

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?