Python is not special in this case. Virtualenv is pretty much equivalent to:

- bundle --path env_directory

- gopath

- any other language's vendoring solution

In Ruby for example you can do "gem install foo" or add foo to Gemfile and use bundler. Those work similar to "pip install foo" or adding foo to pyproject and using poetry.

It was worse and complicated, but for years now it seems like complaining about venv is closer to a meme, since people go away and do pretty much the same thing in other languages. (Or don't have that option in something like C)

I don't know about Ruby, but it's nothing like Gopath or node_modules, nor Yarn PnP for what it's worth. Virtualenv still need to be created per project and must be "activated".

The fact that they're a somewhat hidden stateful context is still complicated and confusing.

The fact is when I retrieve a Python project, I still have no idea what command I should run to install the dependencies and setup everything. With Go modules it's just `go get`, and with JS projects it's just `npm install` or `yarn install`

The concept is the same. I'm not saying the implementation is identical. And I meant gopath before modules - where you have to explicitly define your environment.