Hermetic environments

[DL Neil]

On 25/07/19 10:31 AM, Cameron Simpson wrote:
> On 24Jul2019 19:59, Eli the Bearded <*@eli.users.panix.com> wrote:
>> In comp.lang.python, DL Neil  <PythonList at DancesWithMice.info> wrote:
>>> Is Python going 'the right way' with virtual environments?
>> ...
>>> Am I 'getting away with it', perhaps because my work-pattern doesn't
>>> touch some 'gotcha' or show-stopper?
>>>
>>> Why, if so much of 'the rest of the world' is utilising "containers",
>>> both for mobility and for growth, is the Python eco-system following its
>>> own path?
>>
>> I'm going to speculate that even inside containers, some people will use
>> multiple virtual environments. It could be that the app and the
>> monitoring for that app are developed by different branches of the
>> company and have different requirements.
>>
>> But I think a lot of the use of virtual environments is in dev
>> environments where a developer wants to have multiple closed settings
>> for doing work. On the dev branch, newer versions of things can be
>> tested, but a production environment can be retained for hotfixes to
>> deployed code.
>>
>> Or because the different microservices being used are each at different
>> update levels and need their own environments.
> 
> Yeah. In a recent former life we were maintaining some APIs with many 
> releases (point releases every sprint, for those APIs changing that 
> sprint). The customers could stick with older API revisions if they had 
> special requirements (or simply lacked their own dev time to verify a 
> successful forward version shift), so there were multiple historic 
> versions in play in the field.
> 
>>> Is there something about dev (and ops) using Python venvs which is a
>>> significant advantage over a language-independent (even better: an
>>> OpSys-independent) container?
>>
>> I'm not a big fan of language-dependent virtual environments because
>> they only capture the needs of a particular language. Very often code
>> works with things that are outside of that language, even if it is only
>> system libraries.
> 
> The advantage of the language dependent venv is that it is self 
> contained. You can update, say, the Python component of the project 
> independently of some adjacent other language. This might all be 
> contained within a larger environment which itself is snapshotted for 
> release purposes.
> 
> 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?

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?
(and lose the "hermetic seal" - face the version collisions/combinations 
both philosophies seek to avoid)


NB a problem I experienced yesterday was that VMs are differentiated by 
versionNR and date - but in 'client-language' the date was not when the 
VM was created, but when she last used it. Users!
(nothing is perfect - and yes I found it by 'relative addressing' the dates)
-- 
Regards =dn