Hermetic environments
DL Neil
PythonList at DancesWithMice.info
Wed Jul 24 23:45:54 EDT 2019
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
More information about the Python-list
mailing list