We use poetry inside docker in a very similar way, but use a multistage docker file - the "builder" image has poetry installed and installs the application into a venv, we then copy that venv to the "prod" image and run the application there (so we do not have poetry or any other packages that are only required at build time in the final image).
It's definitely fine with no problems. We used to do this too.
But, it optimizes for something that only matters if you're in a space constrained setup. Turns out for "almost-all" web setups, a few extra hundreds of MBs don't matter even a few GB possibly.
Even in AWS Lambda where cold-start is king, size doesn't matter[0] - I am the top answer. As long as you have fast starts and that's determined by code paths, libraries etc.
So as long as your program readies itself quickly, having gcc and a few other std libs don't impact any key metric.
In there, you'll find the settings.py split by environment (like you would have in the Elixir world), and a multistage Docker image designed to be cache-friendly (for faster Docker builds). Some stages even run the test suite, so it could be compared to a CI pipeline.
Not having build dependencies in the production image is definitely a good approach.
Comments
We use poetry inside docker in a very similar way, but use a multistage docker file - the "builder" image has poetry installed and installs the application into a venv, we then copy that venv to the "prod" image and run the application there (so we do not have poetry or any other packages that are only required at build time in the final image).
Any thoughts on that approach?
It's definitely fine with no problems. We used to do this too.
But, it optimizes for something that only matters if you're in a space constrained setup. Turns out for "almost-all" web setups, a few extra hundreds of MBs don't matter even a few GB possibly.
Even in AWS Lambda where cold-start is king, size doesn't matter[0] - I am the top answer. As long as you have fast starts and that's determined by code paths, libraries etc.
So as long as your program readies itself quickly, having gcc and a few other std libs don't impact any key metric.
[0] https://stackoverflow.com/questions/69512271/will-the-cold-s...
For Django projects, I made a gist as a template of what I use: https://gist.github.com/linkdd/4aac2c2efc4a51af6ca4b05f395de...
In there, you'll find the settings.py split by environment (like you would have in the Elixir world), and a multistage Docker image designed to be cache-friendly (for faster Docker builds). Some stages even run the test suite, so it could be compared to a CI pipeline.
Not having build dependencies in the production image is definitely a good approach.