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

51–60 of 224 posts

Re: My Python Development Environment, 2018 Edition

#51

Post by beagle3 »

natch wrote: post #27

I’m using Anaconda because it was recommended in a step by step tutorial for playing with deep learning. What would be involved in removing it from my system and moving instead to this set of tools? Not necessarily looking for s step by step answer, just for general suggestions. My guess is: find out which python the deep learning tools are using, remove Anaconda, and reinstall the python version needed, using the to…

What do you think you'll get from any if these tools that you do not get from {ana,mini}conda?

I must be missing something, but all these use cases (and more) seem to have been covered by miniconda ages ago.

conda works with perfectly well with pip, and creates virtual environments that are at least (in my experience) as good as virtualenv does.

Re: My Python Development Environment, 2018 Edition

#52

Post by nnq »

ju-st wrote: post #30
pjmlp wrote: post #14

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

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 create an "index db" of your code behind the scenes like PyCharm does, so it can show you usage and search for stuff practically instantly.

Overall VSC is great for developing Python on not-huge and well-behaved projects. For degenerated overgrown messes it's not a good solution :)

Re: My Python Development Environment, 2018 Edition

#53

Post by benaduggan »

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 huge productivity leap being able to use sql serves as containers rather than installing them on the system! so much easier to manage!

Re: My Python Development Environment, 2018 Edition

#54

Post by meddlepal »

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.

Re: My Python Development Environment, 2018 Edition

#55

Post by amenod »

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 production, I usually ship things in a Docker container anyway, so there is no chance of mismatched libraries.

I guess I just never saw a problem that virtualenv solves.

Re: My Python Development Environment, 2018 Edition

#56

Post by meribold »

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)

More than 5: I recently listed all programs for managing virtual environments I could find in a blog post [1] because I find it pretty confusing how many there are.

[1]: https://meribold.github.io/virtual-environments-9487

Re: My Python Development Environment, 2018 Edition

#57

Post by nextos »

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.

Nix is one of the most amazing things created lately. IMHO, it doesn't get the attention it deserves as it provides great solutions to really tough problems and it's ready for prime time.

A purely functional package manager, distro, devops. And pretty soon, home directory management. Maintaining servers or doing aggressive changes becomes very easy. There's even a Darwin (macOS) implementation now, so you can manage most of your Mac functionally (with heavy usage of defaults under the hood).

It's still lacking a bit on usability, as some things are not as intuitive as in a simple imperative distribution such as Arch or Alpine. Especially if you need to run some prepackaged software that assumes FHS and binds dynamically to some pre-existing dependencies.

But to me, right now if you are a moderately advanced user I don't see a point in running distros that are stuck in the middle (imperative, complex, lots of defaults). It's either one extreme (simple and imperative, e.g. Arch) or the other (functional, NixOS).

Re: My Python Development Environment, 2018 Edition

#58

Post by MereInterest »

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.

Re: My Python Development Environment, 2018 Edition

#60

Post by hathawsh »

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)

I use Buildout: http://docs.buildout.org/en/latest/

Buildout is much more than a Python package manager. It runs pluggable recipes, where building/installing a Python package is only one of the many available recipes. It was invented at a company where I once worked. It replaced huge piles of complicated Makefiles.

Buildout is obviously less popular than other solutions, but I think it manages complexity quite well and saves me a lot of time compared with other ways I could assemble Python software.

Post reply on HN