On Fri, May 24, 2019 at 12:42 AM Skip Montanaro <skip.montan...@gmail.com> wrote: > My way of thinking about virtual environments has always leaned in the > direction of a per-application setup, as that requires less > coordination (particularly when deploying to production), but I'm > willing to be convinced to move in fewer-environments-is-better > direction. Here's a concrete question for people who favor fewer > environments: Suppose application #4 requires an update to some > package used by all five applications. What's your protocol for > deployment to test and prod? >
If the applications are separate (such that you could logically and sanely install app #2 on one computer and app #5 on another), separate venvs for each. That does mean that a security or other crucial update will need to be applied to each, but it also keeps everything self-contained; app #1 has a requirements.txt that names only the packages that app #1 needs, and it's running in a venv that has only the packages that its requirements.txt lists. OTOH, if the applications are more closely related, such that you really can't take them separately, then they're really one application with multiple components. In that case, I'd have them all in a single venv (and probably a single git repository for the source code), with multiple entry points within that. That keeps common dependencies together, makes it easier to import modules from one into another, etc. Generally speaking, I would have a single git repo correspond to a single venv, linked via the requirements.txt file(s). Versioning of the source code is thus tied to the versioning of your dependencies and vice versa. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
