5 ms·

How is this better than using a Docker image?

icebraining 9y ago
Docker might replace the need for the virtual environment, but doesn't manage the components of a Python project (building, testing, installing and updating dependencies, etc). Plus, a virtualenv is a much simpler tool, it's essentially just a way to tell the Python interpreter from which directories to load modules, so it's less likely to give you problems.
- yeukhon 9y ago
  It doesn't. Imagine you just want to run some utility written in Python (let's use youtube-dl since it is been on front page lately), why do I need to install Docker to run a simple command? For isolation? No thanks. Virtualenv was created to isolate overwrittkng and installing dependencies. Also, want to emulate multi-sites on single machine deployment? You need virtualenv.
  - icebraining 9y ago
    Docker does solve those problems, even if you and I prefer to use other solutions. And by the way, you don't actually need virtualenv :) we run multiple webapps on a machine by just installing dependencies in a directory (pip -t) in the git repo, and then adding the appropriate PYTHONPATH in the service's startup config. As long as you don't need multiple versions of the Python interpreter, this works fine.
    - eeZah7Ux 9y ago
      > Docker does solve those problems ...with a very computationally expensive solution, and without improving other aspects like security. A systemd unit on a "chroot" can do the same and provide isolation.
      - floatboth 9y ago
        Is it really computationally expensive? Containers/jails/zones are essentially chroots "on steroids", isolating things other than the filesystem (networking, hostname, process IDs, users, etc.)
        0xCMP 9y ago
        Once built a docker container is not expensive, but the idea with Docker is to create immutable, layered containers and rebuilding every time there is a change. Unlike with nodejs, it's harder to volume mount python packages installed in the docker container and so no one does it. Change in requirements means rebuilding the container which is a very computationally and IO expensive process. So if you can get away with it virtualenv is better, but putting everything in a container so you can simply ship a container is also useful. It's a compromise.
        icebraining 9y ago
        Rebuilding the container shouldn't be expensive, that's what layers are for.
        0xCMP 9y ago
        A layer with your pip requirements being added and then installed is the most expensive part of building a python container so if you change your requirements you invalidate the cache for that layer (and possibly the other layers above).
Karunamon 9y ago
Developing inside a docker image seems like needless complexity to me, especially when virtualenv takes care of the python environment isolation already without another layer of indirection. Virtualenvs are just file copies and PATH vars with some tooling.
- gtirloni 9y ago
  Agreed. If you're on Windows/OSX, it also adds a VM between your host and your code and file sharing has terrible performance.
  - dguo 9y ago
    File sharing performance has gotten much better on OS X, at least: https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/ https://blog.docker.com/2017/05/user-guided-caching-in-docke...
    - tekromancr 9y ago
      It's still not /great/. I have had to switch from my mac to a new Win10 laptop for development because the app server in my docker container would take around 2 mins to detect a change and reboot the app server, which then would take a few minutes to reboot. Now it's much closer to realtime. I do hope that docker get's it sorted out soon, as the tooling on windows isn't as good as what I am used to on osx. And by tooling, I mean command line. I am using Cmder with Linux subsystem for Windows, and it STILL isn't half as good as even the terminal built into osx, let alone iterm.
- tekromancr 9y ago
  Maybe if what you are building runs comfortably in one app, on one server, with no important discrepancies between your dev system and production. The environment I work with has docker containers for Web App Server Background Task Worker Server Database Redis Node Cassandra Node Getting all of these to work nicely together on linuxes/macOS/Windows in a repeatable fashion across multiple developers is a major headache. Being able to spin the whole cluster up with `docker-compose up -d` turns the whole mess into merely a minor headache. Most of the time, I only need to work on functionality that depends on DB and WEB nodes, but if I ever need to debug some issue with the worker tasks, it's much easier to have a whole working system available.

Docker might replace the need for the virtual environment, but doesn't manage the components of a Python project (building, testing, installing and updating dependencies, etc). Plus, a virtualenv is a much simpler tool, it's essentially just a way to tell the Python interpreter from which directories to load modules, so it's less likely to give you problems.

yeukhon 9y ago
It doesn't. Imagine you just want to run some utility written in Python (let's use youtube-dl since it is been on front page lately), why do I need to install Docker to run a simple command? For isolation? No thanks. Virtualenv was created to isolate overwrittkng and installing dependencies. Also, want to emulate multi-sites on single machine deployment? You need virtualenv.
- icebraining 9y ago
  Docker does solve those problems, even if you and I prefer to use other solutions. And by the way, you don't actually need virtualenv :) we run multiple webapps on a machine by just installing dependencies in a directory (pip -t) in the git repo, and then adding the appropriate PYTHONPATH in the service's startup config. As long as you don't need multiple versions of the Python interpreter, this works fine.
  - eeZah7Ux 9y ago
    > Docker does solve those problems ...with a very computationally expensive solution, and without improving other aspects like security. A systemd unit on a "chroot" can do the same and provide isolation.
    - floatboth 9y ago
      Is it really computationally expensive? Containers/jails/zones are essentially chroots "on steroids", isolating things other than the filesystem (networking, hostname, process IDs, users, etc.)
      - 0xCMP 9y ago
        Once built a docker container is not expensive, but the idea with Docker is to create immutable, layered containers and rebuilding every time there is a change. Unlike with nodejs, it's harder to volume mount python packages installed in the docker container and so no one does it. Change in requirements means rebuilding the container which is a very computationally and IO expensive process. So if you can get away with it virtualenv is better, but putting everything in a container so you can simply ship a container is also useful. It's a compromise.
        icebraining 9y ago
        Rebuilding the container shouldn't be expensive, that's what layers are for.
        0xCMP 9y ago
        A layer with your pip requirements being added and then installed is the most expensive part of building a python container so if you change your requirements you invalidate the cache for that layer (and possibly the other layers above).

Karunamon 9y ago

Developing inside a docker image seems like needless complexity to me, especially when virtualenv takes care of the python environment isolation already without another layer of indirection. Virtualenvs are just file copies and PATH vars with some tooling.

gtirloni 9y ago
Agreed. If you're on Windows/OSX, it also adds a VM between your host and your code and file sharing has terrible performance.
- dguo 9y ago
  File sharing performance has gotten much better on OS X, at least: https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/ https://blog.docker.com/2017/05/user-guided-caching-in-docke...
  - tekromancr 9y ago
    It's still not /great/. I have had to switch from my mac to a new Win10 laptop for development because the app server in my docker container would take around 2 mins to detect a change and reboot the app server, which then would take a few minutes to reboot. Now it's much closer to realtime. I do hope that docker get's it sorted out soon, as the tooling on windows isn't as good as what I am used to on osx. And by tooling, I mean command line. I am using Cmder with Linux subsystem for Windows, and it STILL isn't half as good as even the terminal built into osx, let alone iterm.
tekromancr 9y ago
Maybe if what you are building runs comfortably in one app, on one server, with no important discrepancies between your dev system and production. The environment I work with has docker containers for Web App Server Background Task Worker Server Database Redis Node Cassandra Node Getting all of these to work nicely together on linuxes/macOS/Windows in a repeatable fashion across multiple developers is a major headache. Being able to spin the whole cluster up with `docker-compose up -d` turns the whole mess into merely a minor headache. Most of the time, I only need to work on functionality that depends on DB and WEB nodes, but if I ever need to debug some issue with the worker tasks, it's much easier to have a whole working system available.