3 ms·

You have to remember to activate them. Node/npm has a similar concept with its scripts execution, but it automatically runs them in the local node_modules envi

You have to remember to activate them. Node/npm has a similar concept with its scripts execution, but it automatically runs them in the local node_modules environment (i.e. virtualenv). You might think this is silly but think about something like making a systemd service to run your python script in a venv--how do you do it? You have to activate the script or call its python bin, but it's not obvious how to do that in any python docs.

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

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