Hermetic environments

[Cameron Simpson]

On 25Jul2019 15:45, DL Neil <PythonList at 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 <cs at cskk.id.au>