How do you organize your virtual environments?

[Chris Angelico]

On Fri, May 24, 2019 at 12:42 AM Skip Montanaro
<skip.montanaro at 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