4 ms·

As a Python developer, I just stay with pip and virtualenv, but I share the smh/wtf sentiment here. The data science folks enjoy conda but I don't see that bein

As a Python developer, I just stay with pip and virtualenv, but I share the smh/wtf sentiment here. The data science folks enjoy conda but I don't see that being useful to me anywhere else. I feel like every other year someone will invent a new pip env. pyvenv (see comment section, edited) is now deprecated and venv is recommended (shipped as part of Python 3.6 installation) is another confusion. Lest not forget the confusion of distuilts and setuptools is like argparse vs optparse in the past (which are both horrible). The experience of using pip and pypi (now Warehouse) is much better than that of Ruby and of NodeJS, but these "2-in-1" tools are just ridiculously "creative". As always, pro-tip: consider using the following to ensure environment is loaded properly when you are deploying production /full_path/env/bin/python myapp.py --workers=3 over source /full_path/env/activate && python myapp.py --workers=3 The latter is fine when you are doing local development in your terminals. If you go on #python IRC channel, every year a group of helpers will collectively recommend one of the above and then perhaps a different one the following year, so please do yourself a favor, just stick to pip and virtualenv.

Cyph0n 9y ago
Conda is especially useful if you want to use scientific packages on Windows.
- SatvikBeri 9y ago
  Yeah, I use pip + virtualenv on most machines (and have for years), but conda is the only one that actually seems to "just work" on Windows.
- yeukhon 9y ago
  Good point, thank you. I don't do much on Windows anymore. But a little search of VS Studio (I know there are some core envelopers working for MSFT) yields this: https://stackoverflow.com/questions/15185827/can-pip-be-used-with-python-tools-in-visual-studio https://stackoverflow.com/questions/15185827/can-pip-be-used... Probably exciting for VS users.
jxm262 9y ago
Apologies if I'm missing something obvious (relatively new to Python), but what's the advantage of loading it the 1st way? I'm currently using conda and do something similar to you're 2nd example `source activate conda-env && python myapp.py`
- yeukhon 9y ago
  I'd like to hear what people think as well, so everyone please fire away. The 1st option is very explicit and doesn't modify your environment. The problem I have with the latter option is not just messing with my environment variable (bulk of it is setting PATH), but what will be changed in future releases. I don't have time to read the activate script (btw, there is one activate script for sh/bash/zsh, csh, fish, and bat, but if you are none of them, which likely a very corner case, you are on your own). Using the 1st method, I am certain the shell isn't being modified and loaded with stuff I don't need, and the command and arguments are explicit (when I look at top, or when I do strace). Generally, you can continue to do #2; I use it when I am doing development, like having multiple terminals up and just source into the environment, then run pytest instead of the full path to pytest. But I highly recommend #1 when you are running your code in production (webapp or not). I am not too familiar with conda so I will defer that to the experts).
lettuce 9y ago
> pyenv is now deprecated and venv is recommended Isn't it `pyvenv` that is deprecated? `pyvenv` != `pyenv`
- yeukhon 9y ago
  Yes, you are right. See, that's the other (#%#$^#$%#$ - excuse my Chinese) confusion. Such conflicting name pyvenv and pyenv, someone really could have picked a better name, whoever came later. Corrected in my post.
  - wyclif 9y ago
    Thanks for saying this! I just spent the last 10 minutes confused by that, trying to figure out what was going on here and what I actually have installed now: ⟩ pyenv --version zsh: correct 'pyenv' to 'pyvenv' [nyae]?
unpythonic 9y ago
If you want to not infect your current shell with the new environment, you can just run it in a subshell by using parentheses: $ ( . /full_path/env/bin/activate && python myapp.py --workers=3 ) This works for anything that you'd like a temporary shell for: $ pwd /home/me $ ( cd /tmp; pwd ) /tmp $ pwd /home/me
jordic 9y ago
python3.6 -m venv . && source bin/activate (this builds around the idea every project is a python package itself). pip install -e .

Cyph0n 9y ago

Conda is especially useful if you want to use scientific packages on Windows.

SatvikBeri 9y ago
Yeah, I use pip + virtualenv on most machines (and have for years), but conda is the only one that actually seems to "just work" on Windows.
yeukhon 9y ago
Good point, thank you. I don't do much on Windows anymore. But a little search of VS Studio (I know there are some core envelopers working for MSFT) yields this: https://stackoverflow.com/questions/15185827/can-pip-be-used-with-python-tools-in-visual-studio https://stackoverflow.com/questions/15185827/can-pip-be-used... Probably exciting for VS users.

jxm262 9y ago

Apologies if I'm missing something obvious (relatively new to Python), but what's the advantage of loading it the 1st way? I'm currently using conda and do something similar to you're 2nd example `source activate conda-env && python myapp.py`

yeukhon 9y ago
I'd like to hear what people think as well, so everyone please fire away. The 1st option is very explicit and doesn't modify your environment. The problem I have with the latter option is not just messing with my environment variable (bulk of it is setting PATH), but what will be changed in future releases. I don't have time to read the activate script (btw, there is one activate script for sh/bash/zsh, csh, fish, and bat, but if you are none of them, which likely a very corner case, you are on your own). Using the 1st method, I am certain the shell isn't being modified and loaded with stuff I don't need, and the command and arguments are explicit (when I look at top, or when I do strace). Generally, you can continue to do #2; I use it when I am doing development, like having multiple terminals up and just source into the environment, then run pytest instead of the full path to pytest. But I highly recommend #1 when you are running your code in production (webapp or not). I am not too familiar with conda so I will defer that to the experts).

lettuce 9y ago

> pyenv is now deprecated and venv is recommended Isn't it `pyvenv` that is deprecated? `pyvenv` != `pyenv`

yeukhon 9y ago
Yes, you are right. See, that's the other (#%#$^#$%#$ - excuse my Chinese) confusion. Such conflicting name pyvenv and pyenv, someone really could have picked a better name, whoever came later. Corrected in my post.
- wyclif 9y ago
  Thanks for saying this! I just spent the last 10 minutes confused by that, trying to figure out what was going on here and what I actually have installed now: ⟩ pyenv --version zsh: correct 'pyenv' to 'pyvenv' [nyae]?

unpythonic 9y ago

If you want to not infect your current shell with the new environment, you can just run it in a subshell by using parentheses: $ ( . /full_path/env/bin/activate && python myapp.py --workers=3 ) This works for anything that you'd like a temporary shell for: $ pwd /home/me $ ( cd /tmp; pwd ) /tmp $ pwd /home/me

jordic 9y ago

python3.6 -m venv . && source bin/activate (this builds around the idea every project is a python package itself). pip install -e .