5 ms·

I'm not sure what you might mean by runtime, but a python venv does make sure you're using the same runtime. There are symlinks in the environments bin director

I'm not sure what you might mean by runtime, but a python venv does make sure you're using the same runtime. There are symlinks in the environments bin directory to the specific runtime. If you're plonking a python3.12 binary over the top of the python3.11 one, then yeah, you'll be using a different one, but that'd be an issue nomatter what you're using. Just don't uninstall your python binaries and you're fine. If you want to package everything up into am image or a zip, you can do that too if you want, but in my 10+ year career I've not had much of an issue just using boring venvs.

adolph 3y ago
If you attempt to reproduce a project in a repo that only includes source and requirements.txt you will not have metadata about the version of Python used. It seems that there is a way to do this in pip but I don’t think it is widely used: https://stackoverflow.com/questions/19559247/requirements-txt-depending-on-python-version https://stackoverflow.com/questions/19559247/requirements-tx...
latexr 3y ago
> but a python venv does make sure you're using the same runtime. It does not. > There are symlinks in the environments bin directory to the specific runtime. Precisely. They symlink to a path. Which means that if you have a certain version of Python at one location (let’s say /usr/bin/python3) and later update that (let’s say by upgrading macOS and the Xcode developer tools), the same virtual environment will point to a different version of Python. > Just don't uninstall your python binaries and you're fine. That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful. The point of the question was to reproduce the same thing without asterisks and you’ve introduced a major one and called it a day.
- camgunz 3y ago
  You can use --copies if you don't want symlinks [0]. [0]: https://docs.python.org/3/library/venv.html https://docs.python.org/3/library/venv.html
  - latexr 3y ago
    Not with the macOS Python from the Xcode developer tools: > Error: This build of python cannot create venvs without using symlinks
    - camgunz 3y ago
      Don't use that one
      - latexr 3y ago
        — Doctor, it hurts when I raise may arm. — Then don’t raise your arm. Like I said in the original comment you replied to and are now ignoring: > That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful.
        scaryclam 3y ago
        This is more like: - Doctor, it hurts when I hit my head on the wall - Then don't hit your head on the wall You have solutions available, use them
        latexr 3y ago
        Apparently, “sometimes you don’t have a choice” is a foreign language. — Hey, so you know how we have this requirement, which came about after years of dealing with and understanding a problem and the available solutions? — Yes, what about it? — Well, a random commenter on Hacker News who has zero context of the problem has suggested we use a method we already found inadequate for our specific use case. — Oh wow, in that case let’s replace the whole system right now.
- scaryclam 3y ago
  The binary installs aren't that generic in the machines I've used (mac and debian based, so covers a fair bit). It's python3.11, not python3, and the python3 "executable" is, itself a symlink to the particular binary (in this example python3.11). Upgrading just changes the symlink, which wouldn't affect the venv, which isn't using python3, it's using python3.11. I didn't introduce anything, I explained how the links are to the versioned binaries, which isn't what you're stating is happening. Edit to add: as someone else also points out, you don't even have to use the symlinked versions, you can use --copies
  - latexr 3y ago
    > It's python3.11, not python3, and the python3 "executable" is, itself a symlink to the particular binary (in this example python3.11). Not for the example I gave. If you’re seeing Python 3.11, you’re definitely not using the /usr/bin/python3 on macOS with is made available by the Xcode CLI tools. That’s at 3.9.6 even on Sonoma. > as someone else also points out, you don't even have to use the symlinked versions, you can use --copies Which, again, doesn’t work for the stated case. https://news.ycombinator.com/item?id=39818732 https://news.ycombinator.com/item?id=39818732
    - scaryclam 3y ago
      Sorry, but yes I am using macOS for work. I use homebrew as xcode is the issue here, not python or macOS. There are solutions to your problem, you just seem resistant to using them.
      - latexr 3y ago
        > There are solutions to your problem, you just seem resistant to using them. No, it is you who are failing to understand. I’m describing to you a real scenario, but it’s not one that bothers me. I don’t need you to come up with a solution and didn’t ask you for it. You need to understand not everyone has the same requirements and tradeoffs you do.
- mega_dingus 3y ago
  This is not the way you're supposed to be using pyenv You're supposed to install a specific version of python in a specific place, with a specific name. Say, /usr/local/python-3.10.6 Use pyenv to use that python. Control that by creating a `.python-version` file that says 3.10.6 You now have a project that uses 3.10.6. Unless, of course, somebody installs a different version in that path - at which point you've got bigger issues Using pyenv to use `/usr/bin/python3` and hoping for the best misses the point
  - latexr 3y ago
    > This is not the way you're supposed to be using pyenv Because that’s not what the conversation is about. It’s about virtual environments.

adolph 3y ago

If you attempt to reproduce a project in a repo that only includes source and requirements.txt you will not have metadata about the version of Python used. It seems that there is a way to do this in pip but I don’t think it is widely used: https://stackoverflow.com/questions/19559247/requirements-txt-depending-on-python-version https://stackoverflow.com/questions/19559247/requirements-tx...

latexr 3y ago

> but a python venv does make sure you're using the same runtime. It does not. > There are symlinks in the environments bin directory to the specific runtime. Precisely. They symlink to a path. Which means that if you have a certain version of Python at one location (let’s say /usr/bin/python3) and later update that (let’s say by upgrading macOS and the Xcode developer tools), the same virtual environment will point to a different version of Python. > Just don't uninstall your python binaries and you're fine. That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful. The point of the question was to reproduce the same thing without asterisks and you’ve introduced a major one and called it a day.

camgunz 3y ago
You can use --copies if you don't want symlinks [0]. [0]: https://docs.python.org/3/library/venv.html https://docs.python.org/3/library/venv.html
- latexr 3y ago
  Not with the macOS Python from the Xcode developer tools: > Error: This build of python cannot create venvs without using symlinks
  - camgunz 3y ago
    Don't use that one
    - latexr 3y ago
      — Doctor, it hurts when I raise may arm. — Then don’t raise your arm. Like I said in the original comment you replied to and are now ignoring: > That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful.
      - scaryclam 3y ago
        This is more like: - Doctor, it hurts when I hit my head on the wall - Then don't hit your head on the wall You have solutions available, use them
        latexr 3y ago
        Apparently, “sometimes you don’t have a choice” is a foreign language. — Hey, so you know how we have this requirement, which came about after years of dealing with and understanding a problem and the available solutions? — Yes, what about it? — Well, a random commenter on Hacker News who has zero context of the problem has suggested we use a method we already found inadequate for our specific use case. — Oh wow, in that case let’s replace the whole system right now.
scaryclam 3y ago
The binary installs aren't that generic in the machines I've used (mac and debian based, so covers a fair bit). It's python3.11, not python3, and the python3 "executable" is, itself a symlink to the particular binary (in this example python3.11). Upgrading just changes the symlink, which wouldn't affect the venv, which isn't using python3, it's using python3.11. I didn't introduce anything, I explained how the links are to the versioned binaries, which isn't what you're stating is happening. Edit to add: as someone else also points out, you don't even have to use the symlinked versions, you can use --copies
- latexr 3y ago
  > It's python3.11, not python3, and the python3 "executable" is, itself a symlink to the particular binary (in this example python3.11). Not for the example I gave. If you’re seeing Python 3.11, you’re definitely not using the /usr/bin/python3 on macOS with is made available by the Xcode CLI tools. That’s at 3.9.6 even on Sonoma. > as someone else also points out, you don't even have to use the symlinked versions, you can use --copies Which, again, doesn’t work for the stated case. https://news.ycombinator.com/item?id=39818732 https://news.ycombinator.com/item?id=39818732
  - scaryclam 3y ago
    Sorry, but yes I am using macOS for work. I use homebrew as xcode is the issue here, not python or macOS. There are solutions to your problem, you just seem resistant to using them.
    - latexr 3y ago
      > There are solutions to your problem, you just seem resistant to using them. No, it is you who are failing to understand. I’m describing to you a real scenario, but it’s not one that bothers me. I don’t need you to come up with a solution and didn’t ask you for it. You need to understand not everyone has the same requirements and tradeoffs you do.
mega_dingus 3y ago
This is not the way you're supposed to be using pyenv You're supposed to install a specific version of python in a specific place, with a specific name. Say, /usr/local/python-3.10.6 Use pyenv to use that python. Control that by creating a `.python-version` file that says 3.10.6 You now have a project that uses 3.10.6. Unless, of course, somebody installs a different version in that path - at which point you've got bigger issues Using pyenv to use `/usr/bin/python3` and hoping for the best misses the point
- latexr 3y ago
  > This is not the way you're supposed to be using pyenv Because that’s not what the conversation is about. It’s about virtual environments.