3 ms·

Developing inside a docker image seems like needless complexity to me, especially when virtualenv takes care of the python environment isolation already without

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.

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.