Is Python going 'the right way' with virtual environments?
Warning: this post may contain Python-heresy.
I don't use any of the Python virtual environments!
I'm not an *ops person either - unless Ops happened to be included
within a wider department. However, in attempting to follow the "Proper
shebang for python3" thread, the following appealed to my mind:
<<<
The truth is that there is no single answer to this problem until you
hermetically seal an environment. Docker comes close, a freestanding
VM does this most completely. But short of that, the ability to decide
to use something other than system-provided tools absolutely IS a
requirement in systems of any scale.
>>>
I do attempt to "hermetically seal" work, building a separate Virtual
Box VM for each customer (and usually more than one).
To be clear, this is less about Python (I use other languages), and more
a method of keeping things completely separate, for privacy and
security. It also allows me to conveniently separate 'dev' from
'prod'/support.
I don't 'fiddle' but leave all the executables where the OpSys loads
them (smarter minds than mine!), and load/pip everything as system-wide
(no thinking necessary!).
With the power of today's machines, I don't really notice* any
performance degradation. There is no hassle about where the binaries may
be found. There is no issue if one client is sticking with an earlier
version but another wants the next iteration of development using some
v3.7+ advancement. Similarly, there's no chance of tripping-over other
clients' feet because some are web-based, some GUI, and some cmdLN!
* we recently ran a test on a fairly compute-heavy statistics
application: the same system on my (relatively old) portable and VBox,
against a 'delivered version' installed natively on a newer and much
bigger (RAM and CPU) Windows 10 box. Guess which little, old,
Fedora-Linux, VBox-slowed machine 'won'!? Whilst the VM imposes an
overhead 'cost', because it can be
stripped-down/lean-and-mean/nothing-that's-unnecessary, the VM seems to
be cost-effective.
(regardless of the above tactics and criteria!)
Standing on principle, I'd like to use a system other than VBox (Oracle)
but it is neatly cross-platform and multi-platform. When eval-time is
available, Docker is definitely on the try-out list (as mentioned in the
quote, above).
Normally, 'delivery' is a matter of duplicating the VM and fitting it
into the client's DNS. It is similarly easy to pass work to A.N.Other,
and presents no problem if there are multiple developers. (providing THE
VM is not (only) on my portable...)
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?
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?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
