7 ms·

I kinda of like this... but then again I'm kind of wary. Isn't the standard library the place where packages go to die? Isn't the reason pip is actually usefu

I kinda of like this... but then again I'm kind of wary. Isn't the standard library the place where packages go to die? Isn't the reason pip is actually useful because has a nice health release cycle (http://www.pip-installer.org/en/latest/news.html http://www.pip-installer.org/en/latest/news.html) and isn't frozen into the standard-library ice age of the past? Won't this make it even harder to build a compliant version of python that runs on mobile devices where you can't install packages (>_> iOS)? I get that it's convenient, I'm not 100% convinced its a good idea. Edit: Reading the PEP in detail its now clear that this is not bundling pip with python (see 'Including pip directly in the standard library'). This is bundling a pip installer as part of the standard library. Much better.

Aaronneyer 13y ago
Ya, this is a good thing. Ruby started shipping with rubygems since 1.9 and it's worked great.
- cls59 13y ago
  And Node started shipping NPM in 0.6.3 --- which has also worked great.
tsurantino 13y ago
Is it the "norm" that, when accepted into the standard library, packages "die" - or is it because this has happened to some packages, the popular perception is that the standard library is where packages go to die. I'm just not understanding how it's OK that a standard acceptance of a Python package really means that it should go to the graveyard.
- DasIch 13y ago
  The standard library only gets new features when a minor or major Python release happens. That doesn't happen very often which slows down development of anything in the stdlib significantly to the point that packages in the stdlib effectively "die". To some extent this is intentional because anything that requires more frequent changes is probably not stable enough for inclusion in the stdlib, in practice it does cause some unintentional issues for example rather lacking timezone support.
jcater 13y ago
It looks like they're taking a new strategy with this move. Pip isn't actually going to be moved to the standard library to live; rather, a new "ensurepip" command that installs "pip" will be a part of Python proper. However, a distributable version of pip will be included with each release so that ensurepip does not have to contact the PyPI servers during an install. And with each maintenance release of Python, this pre-included version will be updated to match the then-current pip release. But, the bottom line is that pip still lives outside of the standard library. Python 3.4+ is just guaranteeing that you have a version installed.
- btel 13y ago
  According to the pep ensurepip was rejected: http://www.python.org/dev/peps/pep-0453/#including-ensurepip-in-python-2-7-and-3-3 http://www.python.org/dev/peps/pep-0453/#including-ensurepip...
  - c0g 13y ago
    For backporting to 3.3/2.7. 3.4 has it.
brian_cloutier 13y ago
> Won't this make it even harder to build a compliant version of python that runs on mobile devices where you can't install packages (>_> iOS)? Why wouldn't you be able to install packages? iOS stops you from making executable pages, but cpython runs bytecode anyway.

Aaronneyer 13y ago

Ya, this is a good thing. Ruby started shipping with rubygems since 1.9 and it's worked great.

cls59 13y ago
And Node started shipping NPM in 0.6.3 --- which has also worked great.

tsurantino 13y ago

Is it the "norm" that, when accepted into the standard library, packages "die" - or is it because this has happened to some packages, the popular perception is that the standard library is where packages go to die. I'm just not understanding how it's OK that a standard acceptance of a Python package really means that it should go to the graveyard.

DasIch 13y ago
The standard library only gets new features when a minor or major Python release happens. That doesn't happen very often which slows down development of anything in the stdlib significantly to the point that packages in the stdlib effectively "die". To some extent this is intentional because anything that requires more frequent changes is probably not stable enough for inclusion in the stdlib, in practice it does cause some unintentional issues for example rather lacking timezone support.

jcater 13y ago

It looks like they're taking a new strategy with this move. Pip isn't actually going to be moved to the standard library to live; rather, a new "ensurepip" command that installs "pip" will be a part of Python proper. However, a distributable version of pip will be included with each release so that ensurepip does not have to contact the PyPI servers during an install. And with each maintenance release of Python, this pre-included version will be updated to match the then-current pip release. But, the bottom line is that pip still lives outside of the standard library. Python 3.4+ is just guaranteeing that you have a version installed.

btel 13y ago
According to the pep ensurepip was rejected: http://www.python.org/dev/peps/pep-0453/#including-ensurepip-in-python-2-7-and-3-3 http://www.python.org/dev/peps/pep-0453/#including-ensurepip...
- c0g 13y ago
  For backporting to 3.3/2.7. 3.4 has it.

brian_cloutier 13y ago

> Won't this make it even harder to build a compliant version of python that runs on mobile devices where you can't install packages (>_> iOS)? Why wouldn't you be able to install packages? iOS stops you from making executable pages, but cpython runs bytecode anyway.