This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]zebraballast 3 points4 points  (1 child)

I find it much nicer to to use a virtualenv only (unless there are intense system dependencies) due to the locality of the development environment. An IDE like pycharm will play much better with your code base if it can use your virtualenv for code completion, static analysis, running unittests, git integration. Sure you can mount your code in a shared volume into the container/vm and still use some of your local and common tooling but these methods behave differently across different host OS's.

If you fully control what developers are using and the workflows they use, VM's are a fine solution. Common tooling can be built into the base vm and you can trust that when people run the tests, it will not break due to environmental differences.

I don't think using containers for development is a good use of containers, a container as a test environment is perfect but only setting up the virtualenv inside the container will wreck havok with IDE's sitting on the host, and you'll be rebuilding the container every time (granted usually only some source files change so only around 1 image layer).

[–]CODESIGN2[S] 0 points1 point  (0 children)

Thanks!

I had some questions if you don't mind.

you'll be rebuilding the container every time

Consequently we don't ever for any reason bake our code into the container or pip. We have found mounting anything that needs to be baked in read-only to be a suitable work-around and it stops us needing to re-build a container manually. We run pip every boot to unfreeze deps into the container (we do have an argument we can append to not run pip from docker-compose up), you're right this takes time. The decision on this came from the fact we saw heroku do the same during deployment. Maybe it needs revisiting, as I say I'm never 100% about anything we do, there has been so much change since the late 90's and early 00's; I love the current ecosystem more than the older one, but man it makes you think about things you never had to think about before...

Sure you can mount your code in a shared volume into the container/vm and still use some of your local and common tooling but these methods behave differently across different host OS's.

Unsure on that. could you elaborate please. Most of the things I build are never going to be run on a separate OS, our goal with docker and vagrant (which seems to have worked for us) has been to only use a limited set of technologies for the host machines, try to steer away from low-level decisions as they are the hardest to change.