On 25Jul2019 15:45, DL Neil <pythonl...@danceswithmice.info> wrote:
In my current life I'm working on a project with a python API and a
JavaScript front end. A release involves building a clean versioned
directory on the server machine; it contains a specific Python venv
inside it; the upper layer is the encapsulation. Example:
STAGING -> app/version2
app-version
venv/....
webapp/javascript-here...
...
app-version2
venv/....
webapp/javascript-here...
...
I still want the venv because it encapsulates the Python arena's
state of play.
Do you use a VCS, eg git or Subversion? Thus, have you disciplined
yourself to check-in work, and subsequently NOT to work on your (old)
copy, but to check-out a fresh copy?
Well of course. Mercurial or git. That's what makes the deploy process
fairly easy, one deploys from a revision with a release tag.
Similarly, rather than adding a second environment or updates to an
existing (prod) VM, it is a 'discipline' to make a copy of the
appropriate VM and work with the (new) copy! (either upgrading some
component of the source, the Python eco-system, or the OpSys)
Copying/backing-up a VM is a rapid operation. So, why would you prefer
to set up a second and separate py-env within an existing environment?
1: it is smaller and much lower overhead. How many _live_ VMs are you
keeping around?
2: no VMs in play at this end.
Cheers,
Cameron Simpson <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
