7 ms·

Docker and Python

12 points by jajjarax 6y ago

MeteorMarc 6y ago
How is this easier than sharing a requirements.txt and a requirements-dev.txt on git and having a venv per python project?
- Pinus 6y ago
  At least it circumvents https://xkcd.com/1987/ https://xkcd.com/1987/ to some extent. It sometimes feels like half the [python] questions on Stack Overflow are from persons confused about how and where packages get installed and what Python they are actually running.
  - boublepop 6y ago
    It doesn’t circumvent anything, it just adds another place that people can potentially be confused. Now you have your site packages in a Linux file system in a container you need to fiddle with, and so you install your packages there in a virtual env? Do you use cobra? Etc. Not saying docker isn’t a good solution sometimes, but if you just want to manage local python dev environments venv will get you through it with far less complexity and far less confusion.
rwdim 6y ago
while i agree this is overly complex given the simplicity of virtualenvs, there is something “pythonic” about encapsulating the environment in a container. I would suggest using alpine containers with python for a ~40mB container, versus the ~900MB container created here to run a server. For me, python containers are only used when I want to bundle things into services on swarm, and I use venvs for local development.
66antigravity 6y ago
First of all, I would rather use docker-compose, not a single docker build, since your app can grow. Speaking of growing, I would separate dev & prod docker-compose. > When we develop more than one python project, we need to configure our development environment with the dependencies of all the projects. use pyenv and simple virtualenvs. I think you are trying to substitute a virtualenvs with a docker. Why trying to kill a sparrow with a cannon?
jamemuraca 6y ago
Nice one! Consider a follow up article with 1. Alpine Linux as the base image to significantly reduce the size and 2. Build the requirements in one layer, and then transfer the codebase to a new layer to further reduce size.

12 points by jajjarax 6y ago

How is this easier than sharing a requirements.txt and a requirements-dev.txt on git and having a venv per python project?

Pinus 6y ago
At least it circumvents https://xkcd.com/1987/ https://xkcd.com/1987/ to some extent. It sometimes feels like half the [python] questions on Stack Overflow are from persons confused about how and where packages get installed and what Python they are actually running.
- boublepop 6y ago
  It doesn’t circumvent anything, it just adds another place that people can potentially be confused. Now you have your site packages in a Linux file system in a container you need to fiddle with, and so you install your packages there in a virtual env? Do you use cobra? Etc. Not saying docker isn’t a good solution sometimes, but if you just want to manage local python dev environments venv will get you through it with far less complexity and far less confusion.

rwdim 6y ago

while i agree this is overly complex given the simplicity of virtualenvs, there is something “pythonic” about encapsulating the environment in a container. I would suggest using alpine containers with python for a ~40mB container, versus the ~900MB container created here to run a server. For me, python containers are only used when I want to bundle things into services on swarm, and I use venvs for local development.

66antigravity 6y ago

First of all, I would rather use docker-compose, not a single docker build, since your app can grow. Speaking of growing, I would separate dev & prod docker-compose. > When we develop more than one python project, we need to configure our development environment with the dependencies of all the projects. use pyenv and simple virtualenvs. I think you are trying to substitute a virtualenvs with a docker. Why trying to kill a sparrow with a cannon?

jamemuraca 6y ago

Nice one! Consider a follow up article with 1. Alpine Linux as the base image to significantly reduce the size and 2. Build the requirements in one layer, and then transfer the codebase to a new layer to further reduce size.