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
> directory on the server machine; it contains a specific Python venv
> inside it; the upper layer is the encapsulation. Example:
> ?STAGING -> app/version2
> ?? venv/....
> ?? ...
> ?? venv/....
> ?? ...
> 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)