Live data from Hacker News

My Python Development Environment, 2018 Edition

jacobian.org

211–220 of 224 posts

Re: My Python Development Environment, 2018 Edition

#211

Earlier quoted context omitted.

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 wit…

I think pretty much everyone would "prefer to use the standard library where possible". But try building a modern web app with that. No one uses libraries because they want to, they use b/c they need to.

> No one uses libraries because they want to, they use b/c they need to.

I'll have to respectfully disagree with this one. Everyone pulls in requests the moment they have to make any kind of http request for the sole reason that it's more ergonomic, not because it's "needed".

And requests brings in 4 of its own dependencies. Right there you've created a prime chance for everything to go sideways (and I've watched it happen explicitly with the requests library as it bolts on more and more ergonomic features).

For what it's worth, the last web app I built had a DB library from the OS vendor, flask, and gunicorn. All of which, since they were quite stable, never introduced library conflicts.

Re: My Python Development Environment, 2018 Edition

#212

I didn't manage to get a run at pyenv, pipsi or pipenv, but for virtualenvwrapper and tmux work great together. I'm running linux at work and usually keep it alive for days, so tmux is used for session keeping and remote work. I've created a few bash scripts which run some tmux commands for setting up the layout as I want it and also execute "workon" for the specific virtualenv. For working on a new project, I've ano…

>What takes a bit too long is setting it up again upon a restart.

Have you tried this tmux plugin? https://github.com/tmux-plugins/tmux-resurrect I use it all the time at work and at home

Re: My Python Development Environment, 2018 Edition

#213
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…

>These are pretty big Flask apps too, which have thousands of lines of code, dozens of packages, tons of assets and require running Celery, Postgres, Redis, etc.. I was trying to create a new project last month trying to put all of these together. One thing that I was stuck in was putting these together: - non-single-thread-Flask - Redis pub-sub, subscribe to listen to a channel - and websocket (such as socket.io) up…

Fanout/Pushpin works here as does having an aiohttp wrapped WSGI Flask app.

Re: My Python Development Environment, 2018 Edition

#214
Forget python development, why is it so damn hard to USE python scripts in a version-correct way in the first place? I have python scripts in my system which rely on different python versions. And since I have a default python version, 2.7 (through symlink or env or whatever), all the python 3 scripts fail until I switch the default version manually (due to library dependencies, print format, etc.). Why don't these scripts add "#!/usr/bin/python3" at the top? And why is it so hard to just have 2 versions co-exist? I MUST be doing something wrong here?

EDIT: "python3 " doesn't always work because some scripts are written in bash and they call python within the script.

Re: My Python Development Environment, 2018 Edition

#215

Earlier quoted context omitted.

Anaconda does most of the stuff mentioned, and also makes it much easier to install packages based on C/C++ libraries (which most deep learning things are). So you're better off staying with anaconda. It's widely used in commercial data science projects so the idea that noone "takes it seriously" as someone else suggests is a bit silly. I assume they're thinking about a different context to data science projects. Tha…

> ... and also makes it much easier to install packages based on C/C++ libraries I hear this often, though I cannot remember ever running into a pip package where this was an issue. Out of curiosity, could someone point me to a pip package and its conda equivalent where this is the case?

Rasterio, fiona and anything else GDAL based always causes me headaches.

Re: My Python Development Environment, 2018 Edition

#216

Earlier quoted context omitted.

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

And virtualenv can be overkill unless you've got multiple clients or legacy commitments.

Or you don't want to hose your system python, or you don't want to shit all over any other work you may be doing, or you want to ever test on anything other than a single (probably polluted if you're screwing around using your system python for everything) environment, or you're a professional using python, or if you want to be taken at all seriously....the list goes on! And yeah, using your system python means you're either not doing any professional/serious work or you're a hack who needs to stop doing anything professionally/seriously.

Re: My Python Development Environment, 2018 Edition

#217
post #216

Earlier quoted context omitted.

And virtualenv can be overkill unless you've got multiple clients or legacy commitments.

Or you don't want to hose your system python, or you don't want to shit all over any other work you may be doing, or you want to ever test on anything other than a single (probably polluted if you're screwing around using your system python for everything) environment, or you're a professional using python, or if you want to be taken at all seriously....the list goes on! And yeah, using your system python means you'r…

Never happened in twenty years, get over yourself.

Manually installed packages are already segregated and can be uninstalled ya know.

Re: My Python Development Environment, 2018 Edition

#218
post #216

Earlier quoted context omitted.

And virtualenv can be overkill unless you've got multiple clients or legacy commitments.

Or you don't want to hose your system python, or you don't want to shit all over any other work you may be doing, or you want to ever test on anything other than a single (probably polluted if you're screwing around using your system python for everything) environment, or you're a professional using python, or if you want to be taken at all seriously....the list goes on! And yeah, using your system python means you'r…

Never happened in twenty years.

Manually installed packages are already segregated and can be uninstalled ya know. Might be a problem if you have no admin skills.

Re: My Python Development Environment, 2018 Edition

#219

Earlier quoted context omitted.

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

Are you mounting your virtualenv into the container somehow? How does your editor see the code/docs for your pip dependencies?

I have not tried it but I imagine this would work fine.

    Project
        Project/venv
        Project/src
And then have the whole project as a volume. Then your editor can see the same files as you have in the container.

Re: My Python Development Environment, 2018 Edition

#220
post #216

Earlier quoted context omitted.

Or you don't want to hose your system python, or you don't want to shit all over any other work you may be doing, or you want to ever test on anything other than a single (probably polluted if you're screwing around using your system python for everything) environment, or you're a professional using python, or if you want to be taken at all seriously....the list goes on! And yeah, using your system python means you'r…

Never happened in twenty years. Manually installed packages are already segregated and can be uninstalled ya know. Might be a problem if you have no admin skills.

Way to miss the point!...all of them! Nobody said anything about manually installed packages being unsegregated or immutable, so let's not put up any more straw men. It's just a stupid way to work.

I think you may be the one without admin skills if you think working on your system Python is anything except reckless. No one cares that you have 20 years of doing it like that, it's a poor argument and shows up a really bad attitude.

Post reply on HN