But couldn't you get the same thing using the virtual environment provided by python? Unless you're using a lot of modules with C extensions, you wouldn't need to install anything outside the virtual environment.
> Unless you're using a lot of modules with C extensions
in my experience only the simplemost applications actually don't need anything outside of vanilla python pip. suddenly the client wants PDF reports and you're setting up e.g. some tex-based printing system with a bunch of host packages needed. only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase.
> only containers give you the peace-of-mind that all dependencies, current and future, can be described as part of the codebase.
Couldn't the same thing be done via the package manager and a RPM spec or deb file where all the necessary dependencies are listed and installed as part of the package? It could be done on a VM or could be done on a machine by keeping track of what dependencies are installed when installing the application and handling uninstallation by removing all newly installed dependencies along with the application.
but why polute host or go back to VM overhead per application if we have already a solution that is easier to handle? even just in terms of build & launch time it's quite a bit more performant to use containers vs. VMs.
The package manager can handle removing pretty much any file it installs when uninstalling, so the host really doesn't get "polluted".
> or go back to VM overhead per application
In a development environment hosted on a VM, several applications can be installed on the VM (rather than having one per VM) to reduce overhead. Then testing and making code changes could be done by running a pip -e (editable) install and modifying code in the working directory, or making the change, repackaging and re-installing, and restarting the daemon.
With a container, at least in my experience, you need to re-build it each time you make a change to the code, which actually takes longer than modifying an editable install or re-building the wheel/RPM and reinstalling it.
But the containerization aspect gives the option to pull up and destroy services without worrying about polluting the host you're in.