5 ms·

> 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... c

> 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 https://www.youtube.com/watch?v=Xtah_05BOe8

hprotagonist 6y ago
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 6y ago
  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 6y ago
  > 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 6y ago
    so put it wherever! it's just a directory, put it where you have write access.
    - pdonis 6y ago
      > 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 6y ago
        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 6y ago
        > 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 6y ago
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 6y ago
  > .. standard practice .. when developing with Python development != deployment.
  - heavyset_go 6y ago
    They're standard for deployment, too.
    - alexchamberlain 6y ago
      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 6y ago
        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 6y ago
        > 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?

hprotagonist 6y ago

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 6y ago
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 6y ago
> 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 6y ago
  so put it wherever! it's just a directory, put it where you have write access.
  - pdonis 6y ago
    > 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 6y ago
      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 6y ago
        > 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 6y ago

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 6y ago
> .. standard practice .. when developing with Python development != deployment.
- heavyset_go 6y ago
  They're standard for deployment, too.
  - alexchamberlain 6y ago
    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 6y ago
      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 6y ago
        > 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?