Hermetic environments
Cameron Simpson
cs at cskk.id.au
Wed Jul 24 18:31:17 EDT 2019
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>
More information about the Python-list
mailing list