6 ms·

python -m venv myenv . myenv/bin/activate <install reqs> <your program> Ensures you have the same python environment. The other part is OS state.

by bvrmn 3y ago

pnt12 3y ago
This approach is full of footguns. Forget to install virtualenv? Have fun getting rid of packages in your global system. Sub-dependencies? You'll have to think of a strategy for it. Most people don't and the reproducibility of their project suffers. Developer vs production dependencies ? You'll have to think of a strategy for it. And I think I'm forgetting one, but that's already enough.
_dain_ 3y ago
>The other part is OS state And that's the whole problem. "The same Python environment" doesn't mean much because it underspecifies the full runtime dependency chain.
- bvrmn 3y ago
  It's inherit problem for all languages based on some runtime. Java, PHP, Ruby, whatever have the same issue. And TBH it's not very major issue to start with. No other solution besides fixed OS (containers, nix) could solve this problem.
  - _dain_ 3y ago
    >No other solution besides fixed OS (containers, nix) could solve this problem. You don't have to use NixOS to use Nix. You can install it on any Linux distro, or MacOS, and use it as your build system.
  - jitl 3y ago
    The link posted solved this problem without containers
    - bvrmn 3y ago
      Github issues for pyenv show a slightly opposite picture.
latexr 3y ago
> Ensures you have the same python environment. But not the same Python runtime, which does not fulfil the request of guaranteeing it works the same later without asterisks.
- scaryclam 3y ago
  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.
wodenokoto 3y ago
In this case you don’t count the standard library as part of your Python environment. Since Python version is not specified neither is the standard library.

python -m venv myenv . myenv/bin/activate <install reqs> <your program> Ensures you have the same python environment. The other part is OS state.

by bvrmn 3y ago

python -m venv myenv . myenv/bin/activate <install reqs> <your program> Ensures you have the same python environment. The other part is OS state.

pnt12 3y ago

This approach is full of footguns. Forget to install virtualenv? Have fun getting rid of packages in your global system. Sub-dependencies? You'll have to think of a strategy for it. Most people don't and the reproducibility of their project suffers. Developer vs production dependencies ? You'll have to think of a strategy for it. And I think I'm forgetting one, but that's already enough.

_dain_ 3y ago

>The other part is OS state And that's the whole problem. "The same Python environment" doesn't mean much because it underspecifies the full runtime dependency chain.

bvrmn 3y ago
It's inherit problem for all languages based on some runtime. Java, PHP, Ruby, whatever have the same issue. And TBH it's not very major issue to start with. No other solution besides fixed OS (containers, nix) could solve this problem.
- _dain_ 3y ago
  >No other solution besides fixed OS (containers, nix) could solve this problem. You don't have to use NixOS to use Nix. You can install it on any Linux distro, or MacOS, and use it as your build system.
- jitl 3y ago
  The link posted solved this problem without containers
  - bvrmn 3y ago
    Github issues for pyenv show a slightly opposite picture.

latexr 3y ago

> Ensures you have the same python environment. But not the same Python runtime, which does not fulfil the request of guaranteeing it works the same later without asterisks.

scaryclam 3y ago
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.

wodenokoto 3y ago

In this case you don’t count the standard library as part of your Python environment. Since Python version is not specified neither is the standard library.