News for hackers. Stuff that matters.
Re:My Python Development Environment, 2018 Edition by yeukhon on Thursday February 22, 2018 @01:27PM (#16439956)
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.

Re:My Python Development Environment, 2018 Edition by unpythonic on Thursday February 22, 2018 @02:28PM (#16440602)
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
Re:My Python Development Environment, 2018 Edition by lettuce on Thursday February 22, 2018 @01:54PM (#16440251)
> pyenv is now deprecated and venv is recommended

Isn't it `pyvenv` that is deprecated? `pyvenv` != `pyenv`

Re:My Python Development Environment, 2018 Edition by yeukhon on Thursday February 22, 2018 @01:58PM (#16440297)
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.

Re:My Python Development Environment, 2018 Edition by wyclif on Friday February 23, 2018 @12:32AM (#16444446)
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]?

Re:My Python Development Environment, 2018 Edition by Cyph0n on Thursday February 22, 2018 @01:37PM (#16440053)
Conda is especially useful if you want to use scientific packages on Windows.
Re:My Python Development Environment, 2018 Edition by yeukhon on Thursday February 22, 2018 @02:01PM (#16440343)
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...

Probably exciting for VS users.

Re:My Python Development Environment, 2018 Edition by SatvikBeri on Thursday February 22, 2018 @01:40PM (#16440087)
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.
Re:My Python Development Environment, 2018 Edition by jxm262 on Thursday February 22, 2018 @01:39PM (#16440072)
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`
Re:My Python Development Environment, 2018 Edition by yeukhon on Thursday February 22, 2018 @01:57PM (#16440284)
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).

Re:My Python Development Environment, 2018 Edition by jordic on Thursday February 22, 2018 @04:19PM (#16441478)
python3.6 -m venv . && source bin/activate (this builds around the idea every project is a python package itself). pip install -e .