Hermetic environments
Cameron Simpson
cs at cskk.id.au
Thu Jul 25 00:43:37 EDT 2019
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>
More information about the Python-list
mailing list