3 ms·

It is silly. You put together a three-line bash script to activate the venv, run a pip install, and call your program. The Python docs do cover this topic, and

by wswope 4y ago

It is silly. You put together a three-line bash script to activate the venv, run a pip install, and call your program. The Python docs do cover this topic, and do so rather well: https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/#creating-a-virtual-environment https://packaging.python.org/en/latest/guides/installing-usi...

jakewins 4y ago
But the problem isn't my python environment - the problem is distributing packages, particularly libraries, to downstream users. That one over there uses virtualenvs and a bash script she wrote, that one just ran "pip" and has 4 different system python installs entangled into each other; that one ran `pipenv install`, that one `poetry add`. How do I ensure that at each customer site, my library has the set of dependencies it needs, with versions that it is known to work with? Each installation method has a different constraint solver, a different means of specifying dependencies.
- wswope 4y ago
  Did you mean to respond here? This is a nonsequitor from the GP I was responding to. Regardless: If your question is "how can I ensure technical end-users have the same set of python packages as I do for the code they run using standard pip+venv?", the answer is to pin dependencies in a requirements.txt file. If your question is "how do I stop end users from installing dependencies for my software cowboy-style?", the answer is to write installation and usage instructions, and/or include an AIO run script. If your question is "how do I package my library so that end users' package managers know my library's downstream dependencies when they install it?", you build a wheel using `pip wheel`, which again relies on a requirements.txt. If I'm understanding you right, you're mistaken that you have to handle the package managers separately; they all use pip + wheels under the hood. Conda is a bit of an asterisk in that you can package things differently if you desire, but it plays nice with pip + wheel builds too. https://docs.conda.io/projects/conda-build/en/latest/user-guide/wheel-files.html https://docs.conda.io/projects/conda-build/en/latest/user-gu...

by wswope 4y ago

jakewins 4y ago

But the problem isn't my python environment - the problem is distributing packages, particularly libraries, to downstream users. That one over there uses virtualenvs and a bash script she wrote, that one just ran "pip" and has 4 different system python installs entangled into each other; that one ran `pipenv install`, that one `poetry add`. How do I ensure that at each customer site, my library has the set of dependencies it needs, with versions that it is known to work with? Each installation method has a different constraint solver, a different means of specifying dependencies.

wswope 4y ago
Did you mean to respond here? This is a nonsequitor from the GP I was responding to. Regardless: If your question is "how can I ensure technical end-users have the same set of python packages as I do for the code they run using standard pip+venv?", the answer is to pin dependencies in a requirements.txt file. If your question is "how do I stop end users from installing dependencies for my software cowboy-style?", the answer is to write installation and usage instructions, and/or include an AIO run script. If your question is "how do I package my library so that end users' package managers know my library's downstream dependencies when they install it?", you build a wheel using `pip wheel`, which again relies on a requirements.txt. If I'm understanding you right, you're mistaken that you have to handle the package managers separately; they all use pip + wheels under the hood. Conda is a bit of an asterisk in that you can package things differently if you desire, but it plays nice with pip + wheel builds too. https://docs.conda.io/projects/conda-build/en/latest/user-guide/wheel-files.html https://docs.conda.io/projects/conda-build/en/latest/user-gu...