Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Explicit bootstrapping of pip in Python installations

python.org

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Explicit bootstrapping of pip in Python installations

#41

Post by DasIch »

tsurantino wrote: post #40
shadowmint wrote: post #30

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 ) 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…

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.

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.

Re: Explicit bootstrapping of pip in Python installations

#42

Post by tbatterii »

Shish2k wrote: post #24
tbatterii wrote: post #18

Earlier quoted context omitted.

when virtualenv was released with python 3.3 it didnt come with pip.

Didn't come with it , or didn't install it by default ? AFAIK the default virtualenv behaviour has been "create an environment and then automatically and immediately install pip from the internet", so for the last several years they've been practically tied together, even if they were distributed individually.

i think you are confusing virtualenv with pyvenv which is what came with python 3.3 http://www.python.org/dev/peps/pep-0405/

Re: Explicit bootstrapping of pip in Python installations

#43

Post by zackkitzmiller »

tomrod wrote: post #19
cjbprime wrote: post #10

This isn't very big news, in that virtualenv already provides pip in each new env, and you should not be using pip outside virtualenv -- unless it's to install virtualenv!

I have no idea how to get virtualenv working. I'm that user that needs it for now!

virtualenvwrapper will be a life saver for you.

Re: Explicit bootstrapping of pip in Python installations

#44

Post by jcater »

shadowmint wrote: post #30

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 ) 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…

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.

Re: Explicit bootstrapping of pip in Python installations

#45

Post by X-Istence »

TylerE wrote: post #13
cjbprime wrote: post #10

This isn't very big news, in that virtualenv already provides pip in each new env, and you should not be using pip outside virtualenv -- unless it's to install virtualenv!

We're not all building web apps in python - virtualenv is not universally useful. (Edit: Not that I don't like virtualenv when it's appropriate, but it really bugs me the wrong way when people just throw out generalizations like that)

I build web apps, but almost anything else I do, including a full Python based backend for $WORK is all done in a virtualenv. Virtualenv's are not just for web apps.

Re: Explicit bootstrapping of pip in Python installations

#46

Post by pekk »

jdp wrote: post #31

Hopefully it will also bring about some improvements to pip. It's a pretty great tool but with a couple major caveats. The first is that although it supports many forms of package specification, including VCS repositories, it does not report the package spec according to the way that it was installed, but rather according to the package name and version according to its setup.py. Say you install a package from a git…

I have to say, these are kind of obscure corner cases. Should be fixed, to be sure, but I don't think they are an accurate representation of pip to people who are not familiar.

What do you expect me to use as an alternative? easy_install?

Re: Explicit bootstrapping of pip in Python installations

#47

Post by pekk »

arturadib wrote: post #9

Look at the trails Node + NPM have blazed. That's the right move. Next up: Local package installs.

Python has had a good installer forever. The only difference is that it wasn't centrally mandated. If you need something to be centrally mandated in order to use it, I feel for you.

Re: Explicit bootstrapping of pip in Python installations

#48

Post by pekk »

bbernoulli wrote: post #21

I like pip, but it's too bad that it can only install from source. It's quite a hassle sometimes to round up dependencies and build them all on windows (not to mention not everyone has a compiler installed on windows). easy_install can install from binary installers or eggs. I'd like to see that added to pip.

This is blatantly untrue, pip installs wheels. eggs are dead, easy_install is dead. let them die. We are talking about Python 3.4 here, after all.

Re: Explicit bootstrapping of pip in Python installations

#49

Post by btel »

jcater wrote: post #44
shadowmint wrote: post #30

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 ) 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…

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…

According to the pep ensurepip was rejected: http://www.python.org/dev/peps/pep-0453/#including-ensurepip...
Post reply on HN