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 <pythonl...@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
--
https://mail.python.org/mailman/listinfo/python-list
