Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Python Development Environment, 2018 Edition

jacobian.org

Post reply on HN
Print view View original

71–80 of 224 posts

Re: My Python Development Environment, 2018 Edition

#71

Post by MarcScott »

smt88 wrote: post #61
MarcScott wrote: post #34

Since switching to nixos, my Python development environment couldn't be more satisfying. I use a default.nix file and a requirements.txt file and then with a single command I'm into a shell and virtual environment with all dependencies and packages installed, that I can easily transfer between machines. That is unless I want to use PyQt5.

Do you use NixOS in production?

I'm an educator, so my answer would have to be no, unless we're talking about producing educational material.

People do though.

Re: My Python Development Environment, 2018 Edition

#72

Post by unpythonic »

yeukhon wrote: post #13
mlevental wrote: post #10

there are way too many python dep/env managers/things pipenv pyenv mkvirtualenv virtualenv pipsi venv pew conda virtualenvwrapper i'm sure i'm forgetting like 5. this is like https://xkcd.com/927/ for the record i use pyenv and virtualenv (although playing with ML i'm using conda)

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…

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

#73

Post by kstrauser »

dangerboysteve wrote: post #68

Would it be easier to use individual docker containers, each their own python environment and then have your source directory mapped to a docker directory?

pipenv makes it pretty trivial to get the same effect but without Docker. It also means that your favorite dev tools have easy access to the code you're working on.

Re: My Python Development Environment, 2018 Edition

#74

Post by jimnotgym »

benaduggan wrote: post #53
ben_jones wrote: post #21

I haven't had to write python in awhile but are there reasons to use virtualenv etc. instead of a docker container?

I actually prefer to use Docker, especially on projects with multiple people. The amount of times people shipped code without adding dependencies, or on-boarding new people who wouldn't read the docs to install system dependencies was astounding. Now it's as easy as install Docker, and running `docker-compose up` and since our CI and servers use the same images it's virtually guaranteed to work. I've also noticed a h…

> install system dependencies

This is the important point of Docker. If your app has dependencies that are outside of the Python ecosystem (especially the pita ones to install) Docker seems like an excellent solution. I have an app that requires Oracle drivers and some other binaries with custom compile options (not available through apt) on Linux and I really wish I had built it in Docker.

Re: My Python Development Environment, 2018 Edition

#75

Post by zie »

nnq wrote: post #52
ju-st wrote: post #30

Earlier quoted context omitted.

How does it compare to PyCharm?

It's on par, as long as you don't do too many refactors on nasty codebases. Now, PyCharm chokes on those nasty refactors too, guessing the right stuff only 70% the stuff in a way that sometimes feels purely random, but at least its find and refactor preview UIs save the day sort of... One thing that annoys me on VSC is that some operations (jump to defnition etc.) have delays on larger projects, because it does not c…

Just an FYI..

The parent comment was about Visual Studio(https://www.visualstudio.com/vs/python/), and you seem to be commenting about Visual Studio Code(http://code.visualstudio.com), which are 2 totally different products.

Microsoft has terrible naming practices.

Re: My Python Development Environment, 2018 Edition

#76

Post by zodiac »

masklinn wrote: post #63
zodiac wrote: post #43

Earlier quoted context omitted.

npm installs to a local node_modules file by default, whereas you have to set up a virtualenv or something similar to get that from pip

My understanding is that's what pipenv gives you. You call pipenv install, it creates a venv if necessary and fills it. If you want to run tools within the env, you call pipenv run {command}.

Yes, you're absolutely right, I was comparing npm specifically to pip (without any additional tools like pipenv).

Re: My Python Development Environment, 2018 Edition

#77

Post by book_mentioned »

MereInterest wrote: post #58
meddlepal wrote: post #54

I have added PyInstaller ( http://www.pyinstaller.org/ ) to my toolchain recently for working with Python app distribution. It gets me pretty close to the Golang single distributable executable ideal... the main issue is needing to build on each target OS, which kind of sucks but I can deal with.

I've used pyinstaller on Wine in order to make Windows executables from Linux. Haven't figured out yet how to cross-compile for OSX yet, but that at least reduces it from requiring three major OSes to build to two.

Have you had a chance to evaluate https://pybee.org ?

src: https://news.ycombinator.com/item?id=16419628#16420689

Re: My Python Development Environment, 2018 Edition

#78

Post by meddlepal »

MereInterest wrote: post #58
meddlepal wrote: post #54

I have added PyInstaller ( http://www.pyinstaller.org/ ) to my toolchain recently for working with Python app distribution. It gets me pretty close to the Golang single distributable executable ideal... the main issue is needing to build on each target OS, which kind of sucks but I can deal with.

I've used pyinstaller on Wine in order to make Windows executables from Linux. Haven't figured out yet how to cross-compile for OSX yet, but that at least reduces it from requiring three major OSes to build to two.

We have low interest in Windows support for our software so I haven't even tried yet but WINE is a good idea if it works. For MacOS a TravisCI Mac build should do the trick. It'd be nice if it could all be done in a single run..., but it doesn't seem possible.

Re: My Python Development Environment, 2018 Edition

#79

Post by smortaz »

pjmlp wrote: post #14

I just have latest Python installed and the nice support on Visual Studio. https://www.visualstudio.com/vs/python/

Thanks pjmlp!

Just a note of clarification. There are two "visual studio"s:

https://www.visualstudio.com/vs/python/

This is the classic Visual Studio & runs on Windows only, is a full featured IDE and has goodies like mixed mode Python/C++ debugging.

https://code.visualstudio.com/docs/languages/python

This VS Code, a cross-platform Editor++ with Python support.

Both are being actively worked on and will see continuous improvements.

[disclaimer: manage the dev team]

Re: My Python Development Environment, 2018 Edition

#80

Post by eesmith »

amenod wrote: post #55
pjmlp wrote: post #14

I just have latest Python installed and the nice support on Visual Studio. https://www.visualstudio.com/vs/python/

This, me too. I never understood the need for virtualenv and similar. Do people really encounter trouble with conflicting packages that often? I try to write scripts so they run on different versions of python anyway, unless there is a very specific reason why that is not possible; and even then you can run python versions in parallel on a Debian/Ubuntu box, with different pip installs for each of them. As for produc…

The linked-to essay describes several reasons why the author uses virtualenv. Which of them don't you understand?

My package supports several optional back-ends, selectable at run-time, and it runs under Python 2.7 and 3.6+. I use tox to manage different virtualenvs for the combination of {backend X but not Y or Z, Python 2.7}, {backend X but not Y or Z, Python 3.6}, etc. for Y, and Z, as well as {backend X and Y and Z} for the two versions. Oh, and I support several releases of each of the X, Y, and Z. That's a lot of virtualenvs.

Usually I only develop on the X+Y+Z version because full test suite across all the combinations takes about 15 minutes.

I also do coverage testing, and the Python coverage tool isn't hard to use under this setup to combine tox results across multiple virturalenvs.

I don't know if Docker is better. I've been using this setup for some years.

Post reply on HN