Hermetic environments

[DL Neil]

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