3 ms·

> The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. The problem is that in the python ecosyste

> The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. The problem is that in the python ecosystem there really isn't a default de facto standard yet at all. It's supposed to be pip, but enough people dislike pip that it's hard as a newcomer to know if it's actually the standard or not. The nice thing about putting something like this on a pedestal is that maybe it could actually become a standard, even if the standard should be simple and get out of the way. Better to have a standard that's a bit over the top than no standard at all.

benatkin 2y ago
It feels even more standard than it used to, with python -m pip and python -m venv making it so it can be used with a virtalenv even if only python or python3 is in your path.
- lolinder 2y ago
  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.
  - zahlman 2y ago
    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.
- zahlman 2y ago
  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/_bundled 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/__init__.py 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.

benatkin 2y ago

It feels even more standard than it used to, with python -m pip and python -m venv making it so it can be used with a virtalenv even if only python or python3 is in your path.

lolinder 2y ago
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.
- zahlman 2y ago
  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.
zahlman 2y ago
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/_bundled 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/__init__.py 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.