My understanding is yes and I believe you are describing NixOs (https://nixos.org/)

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.

> but why polute host

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.

typically on a dev PC you'll have multiple apps roled out for development / maybe feature testing. if this is done directly on the host it's always possible for these environments to influence each other. very common is to forget to script a dependency, which only may get recognized once someone wants to deploy on a fresh installation.

Yes, but dependencies are handled by the package manager. So if one is missing, it's a simple matter of adding it to the list of dependencies.

In any case, the point I was trying to make is that the development cycle with containers, in my experience, is slower because you have to go through the build step every time you make a change. For an intpreted language like python, that shouldn't be necessary until close to the end where you test a fresh build before submitting the changes for review.

The setup is a bit more involved, but this can be mitigated in several ways. One is docker or SSH plug-ins in editors like VS code coupled with an SSH server included in the develop build phase, like you would use to develop on a remote server. The other approach is adding the source tree as a volume. You can also do a mixed approach where development is done on host, but testing and deployment is done in docker.