Just for the record, `venv` has been in since Python 3.3, although it didn't bootstrap Pip into the environment until 3.4 and wasn't the officially blessed way of doing things until 3.5 (which was still over 9 years ago).

Pip isn't part of the standard library; the standard library `ensurepip` (called from `venv`) includes a vendored wheel for Pip (https://github.com/python/cpython/tree/main/Lib/ensurepip/_b...), and imports Pip from within that wheel to bootstrap it. (Wheels are zip files, and Python natively knows how to import code from a zip file, so this just involves some `sys.path` manipulation. The overall process is a bit complex, but it's all in https://github.com/python/cpython/blob/main/Lib/ensurepip/__... .)

This is why you get prompted to upgrade Pip all the time in new virtual environments (unless you preempt that with `--upgrade-deps`). The core development team still wants to keep packaging at arms length. This also allows Pip to be developed, released and versioned independently.

Oh, it's certainly more standard than it used to be, and maybe it's on the way to being fully standard. But it definitely hasn't arrived in the spot that npm, cargo, hex, bundler, and similar have in their respective ecosystems.

Npm is a pretty good example of what pip should be. Npm has had to compete with other package managers for a long time but has remained the standard simply because it actually has all the basic features that people expect out of a package manager. So other package managers can spin up using the npm registry providing slightly better experiences in certain ways, but npm covers the basics.

Pip really does not even cover the basics, hence the perpetual search for a better default.

Pip intentionally and by design does not cover package management. It covers package installation - which is more complex for Python than for other languages because of the expectation of being able to (try to) build code in other languages, at install time.