Hermetic environments

[Cameron Simpson]

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.

Cheers,
Cameron Simpson <cs at cskk.id.au>