Thanks!

We experienced that exact same pain. Whether it's pip or Bundler, I can't tell you how many times I've installed and reinstalled requirements.

Sharing data volumes is kind of a hack to make it really easy to keep part of a container around when you delete and recreate a container. I would love to see persistent data volumes become first class citizens so you don't have to create a separate container for them.

For now, though, it's saved us from having to put everything directly into the image in development.

You'll be able to create volumes as first class citizens in the next Docker release with the new 'docker volumes' command if I'm not mistaken: https://github.com/docker/docker/blob/4b4597ae17d4fd8843aa93...

Yes, I'm looking forward to it! It will still be a little ways off before we can use it with Compose, however.

Install each of the pip/bundler requirements with a separate dockerfile RUN command. Each gets cached into its own container filesystem layer that way and only new requirements are pulled. Use your favourite templating tool to generate the dockerfile with multiple run commands.

I wrote djtempl ( https://github.com/emailgregn/djtempl ) for my purposes.

But let's say a dependency is changed. Won't modifying that RUN directive invalidate the cache for everything after it, potentially rebuilding a ton of stuff anyway?

Yup, that's the trade-off.

It's unfortunate that Docker uses an imperative model. A functional model would have much better cache utilization.

I'm not sure if this address your specific pain point, but if your issue is around building images, if you first COPY requirements.txt and then do `pip install` before COPYing the rest of your code into the image, Docker caching will actually cache that layer for you.