[pvg]

For years, I have used Virtualenv

Isn't this just a variant of what the original comment is critiquing, though? In order to sanely use Python and external dependencies you need some highly stateful, magical tool that does 'environments' for you. The conceptual load of this is quite high. Adding docker only makes it higher - now you're not merely 'virtualizing' a single language runtime but an entire OS as well - just to deal with the fact your language runtime has trouble handling dependencies.

[fock]

if the conceptual load of having a large collection of binaries separately from your project (and ready for reuse!) is that high, you probably should use something else. I wonder how C/C++ people just manage this hardship...

(and for all npm-friends: it's exactly the same "conceptual load" which arises from having node 8 and 12 around. except that these will be just incompatible by default, so noone bothers)

[pvg]

I don't understand the point you're making, where does a 'large collection of binaries' come in? The thing I'm talking about is right in the name 'virtual environment'. Or are you simply answering the GP's comment about this being a potential wart in Python with the suggestion that people should just use something else?

[fock]

the point is that the classic virtualenv does not take care of different base distributions (3.5,3.6,3.7...). You have to install them yourselves and switch them in your PATH before setting up a virtualenv. if this is too much "conceptual load", I wish the parent good luck with finding something not having this problem ;). If there are binaries involved, there is the additional problem that you also depend on compiler features and C-libs, which I wish everyone good luck in replicating in their CI for any language (containerization and NixOS/guix/spack are approaches to that problem)

[pvg]

I think we are talking about completely different things. Forget the actual virtualenv and Python for a sec.

Imagine you want to check out the hypothetical language Jagoust. This goes something like so - you install Jagoust and maybe some Jagoust tools. You fire up your interactive environment and set it up so it knows where Jagoust and its tools are. Using your enviornment you do things like tell Jagoust where your project is or which particular version of Jagoust to use, etc.. And that's pretty much it and while the details are different, the process is quite familiar to you since it just leverages your standard interactive environment in ways mechanically similar to Rugoja, another language you know.

Later you decide you want to try the language Snek. The first thing you notice in the Snek tutorial is that your standard interactive environment is somehow not good enough - you need a meta-environment for it and your project. Perplexed, you google some more docs and ask some Snek people and find out that meta-environment used to be how things were done but these days, you probably want a quasi- or para-environment. But why do you need an environment for your environment? You do not know. Such are the mysteries of the Snek.

[fock]

Well, you need some way to switch between different variants of Jagoust in the first setup too? And if everything is so well integrated (w/o bash-scripts and all...), just name Jagoust ;).

Noone forces people to use virtualenvs with "snek"/Python. They can always install python somewhere and "pip install" packages into the installation hierarchy, switching around different hierarchies with bash-scripts (and now have a look what all the other interactive environments do...).