Live data from Hacker News

My Python Development Environment, 2018 Edition

jacobian.org

141–150 of 224 posts

Re: My Python Development Environment, 2018 Edition

#141
post #55
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…

I've found that the library dependency issues appear in direct proportion to the number 3rd party libraries you use. If you're mostly developing against the standard library with a handful other stable libraries, it's not an issue. If you're developing with a requirements.txt (or pipfile) with 10 or more entries, you'll start running into conflicts on a regular basis.

It can also occur as projects age, especially with 3rd party libraries who don't provide API backwards compatibility (which I fully acknowledge is a PITA to develop for, more effort than is frequently justifiable).

Both of these are why I prefer to use the standard library when possible. It's going to remain API stable for a very long time, and the occasional 2-3 lines of boilerplate to do HTTPS requests (and other similar convenience functions) is a cost I'm willing to bear for that stability.

Re: My Python Development Environment, 2018 Edition

#142

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?

I guess, if you are cool with sharing the images when you need to share the environment. I think I just never liked the "bulk" that comes with Docker, though it has gotten better. I think Docker is cool in general but for other stuff than this specific use-case.

i use docker for all the related services.. postgres, redis, solr, zeo... but i use virtualenv and pip. I also use setup.py for declaring entrypoints and coordinate all the services (i don't like too much the docker compose aproach). also i'm using docker.py and boto3 for the devops part.

Re: My Python Development Environment, 2018 Edition

#143
post #113

I'm a big fan of using Docker because for real world web app development, your app is often more than just getting Python and a virtualenv set up. Earlier this week I wrote about the pains of setting up a Python development experience without Docker, and then compared it to Docker as well. If anyone is curious, that's located at https://nickjanetakis.com/blog/setting-up-a-python-developme... . By the way, I would say…

My problem with using Docker (only) is that it doesn't translate well to editors. Like, using jedi-vim[1] with a virtualenv constructed by a Docker container doesn't work at all. Unless I actually run vim itself inside said container. So unless your dependences build on macOS (like in my case), everything goes out the door. [1] https://github.com/davidhalter/jedi-vim

Emacs has pretty nice integrations with inferior docker processes. I'm getting them via spacemacs, so I'm not sure what specific package provides it, but I assume it's elpy.

Re: My Python Development Environment, 2018 Edition

#144
post #113

I'm a big fan of using Docker because for real world web app development, your app is often more than just getting Python and a virtualenv set up. Earlier this week I wrote about the pains of setting up a Python development experience without Docker, and then compared it to Docker as well. If anyone is curious, that's located at https://nickjanetakis.com/blog/setting-up-a-python-developme... . By the way, I would say…

My problem with using Docker (only) is that it doesn't translate well to editors. Like, using jedi-vim[1] with a virtualenv constructed by a Docker container doesn't work at all. Unless I actually run vim itself inside said container. So unless your dependences build on macOS (like in my case), everything goes out the door. [1] https://github.com/davidhalter/jedi-vim

We've got about 30+ backends in python all wrapped in docker containers. Majority of the team was pure vim before I joined and they're slowly converting to pycharm after seeing how nicely you can setup a remote interpreter against a docker container. And it has vim bindings so you don't have to re-learn new hotkeys.

I've also been following this VS Code issue on adding remote docker support for python https://github.com/Microsoft/vscode-python/issues/79#issueco...

However, if you're a hardcore vim guy then I doubt these IDEs are gonna satiate your current flow.

Re: My Python Development Environment, 2018 Edition

#145
post #92

Earlier quoted context omitted.

I use virtualenv so I can just easily `pip freeze > requirements.txt` for individual projects.

pipenv is basically the next level of this process: it records every install and locks only the things you installed rather than their dependencies which often change over time.

I'm a bit confused by this statement, do you mean:

I install foo 1.0, which depends on frob >= 1.0 (which happens to be frob 1.1 when I installed it). Foo 1.1 comes out, as does frob 1.2 and 1.3. If I reinstall from the pipfile, do I get foo 1.0 with frob 1.3?

I ask because that sounds like a bug waiting to happen. IMO, frozen requirements should remain frozen.

Re: My Python Development Environment, 2018 Edition

#146

Earlier quoted context omitted.

So you're using Docker instead of virtual environments? I feel there is much more overhead with Docker, but I could be wrong. Maybe I need to try it out again!

No, it's pretty much the same as you remember it. Using docker instead of just a normal virtualenv is overkill.

Overkill - Yes and No. Yes, because you are spinning up a full VM to run a docker container locally. No, because the container is also the container run in prod, with no opportunity for some other process to come along and hose your otherwise clean install.

The process and FS isolation also make sysadmin-me all tingly inside. That way you can't hose up anybody else's clean install either (even if you're compromised).

As a side note, on mac, the VM that runs docker containers requires less ram and CPU than Hipchat. Go figure.

Re: My Python Development Environment, 2018 Edition

#147
I prefer virtualenv + pip.

I primarily develop on Fedora which ships both Python 2.7 and Python 3.6.

pip and virtualenv are built into python3, no need to install anything. Additionally, these tools + tox are commonly used for python testing in popular python projects [0]. I have found other colleagues that use other tools struggle with pip and virtualenv, and it puts them at a disadvantage when it comes to working with the larger python software community IMO.

[0] https://github.com/pallets/flask/blob/master/.travis.yml

Re: My Python Development Environment, 2018 Edition

#148
post #113

I'm a big fan of using Docker because for real world web app development, your app is often more than just getting Python and a virtualenv set up. Earlier this week I wrote about the pains of setting up a Python development experience without Docker, and then compared it to Docker as well. If anyone is curious, that's located at https://nickjanetakis.com/blog/setting-up-a-python-developme... . By the way, I would say…

My problem with using Docker (only) is that it doesn't translate well to editors. Like, using jedi-vim[1] with a virtualenv constructed by a Docker container doesn't work at all. Unless I actually run vim itself inside said container. So unless your dependences build on macOS (like in my case), everything goes out the door. [1] https://github.com/davidhalter/jedi-vim

Ever heard about bind mounting? My current docker image for a Flask app doesn't even contains my code.

Re: My Python Development Environment, 2018 Edition

#149
post #126

Earlier quoted context omitted.

pipenv is more like yarn (same version locking concept)

If I remember correctly the newest npm does the same though.

Yeah, npm and yarn are pretty close at the moment. Yarn had a big advantage when it was first release, but npm seems to have caught up.

Re: My Python Development Environment, 2018 Edition

#150
> I use multiple OSes: macOS at work, and Linux (well, Linux-ish - actually it’s WSL) at home.

This is pedantry, and the article is otherwise quite informative, but describing WSL as "Linux-ish" is like describing a speedboat as "car-ish" because they both happen to have steering wheels.

WSL is a bloody marvel of engineering, but it is in no way an equivalent of Linux. I'm mentioning this because WSL proponents and detractors tend to miss the fact that understanding those differences is critical to understanding and using--even in trivial ways--WSL itself.

Post reply on HN