For my own education: Python with a good standard packaging system and solid, standard async capabilities would be solidly going after the same areas Node.js has done so well in? If not, why not?
Explicit bootstrapping of pip in Python installations
51–60 of 78 posts
Re: Explicit bootstrapping of pip in Python installations
#52I 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…
Ya, this is a good thing. Ruby started shipping with rubygems since 1.9 and it's worked great.
And Node started shipping NPM in 0.6.3 --- which has also worked great.
Re: Explicit bootstrapping of pip in Python installations
#53Earlier quoted context omitted.
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...
For backporting to 3.3/2.7. 3.4 has it.
Re: Explicit bootstrapping of pip in Python installations
#54Look at the trails Node + NPM have blazed. That's the right move. Next up: Local package installs.
npm badly re-implements what others have done dozens of times. The whole node ecology suffers heavily from "not invented here" syndrome.
Re: Explicit bootstrapping of pip in Python installations
#55For my own education: Python with a good standard packaging system and solid, standard async capabilities would be solidly going after the same areas Node.js has done so well in? If not, why not?
I doubt it. All Node.js libraries are built around the non-blocking model which is why it works so well. Python libraries will have to decide if they're a normal blocking library or an async one. Possibly maintain both versions of the API?
Personally I'm not convinced that the Node.js callback hell is a good way to get high IO performance. The Golang way of doing it with normal, blocking libraries and Goroutine's seems ideal as it doesn't burden the programmer as much.
Re: Explicit bootstrapping of pip in Python installations
#56Hopefully 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?
You're right, maybe I've mis-categorized as them major caveats, but they're not so obscure because both myself and others have had to wrestle with these properties in production. I'm not saying use easy_install by any stretch (pip is great), they already have open tickets and I hope to see them fixed before being rolled into Python proper and do become defining problems within pip.
Re: Explicit bootstrapping of pip in Python installations
#57This 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 agree with paulgb and others -- most of my past work with python could be called scientific programming in one way or another and pip has been enormously useful.
Re: Explicit bootstrapping of pip in Python installations
#58This 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)
fully agreed. the numpy, scipy, matplotlib, PyQt4 stack in particular is very indifferent to virtualenvs: you're going to need to install a whole ton of dependencies system-wide regardless.
i recommend it to everyone i work with, but it is significantly more useful when all your dependencies are pure python.
Re: Explicit bootstrapping of pip in Python installations
#59For my own education: Python with a good standard packaging system and solid, standard async capabilities would be solidly going after the same areas Node.js has done so well in? If not, why not?
I doubt it. All Node.js libraries are built around the non-blocking model which is why it works so well. Python libraries will have to decide if they're a normal blocking library or an async one. Possibly maintain both versions of the API? Personally I'm not convinced that the Node.js callback hell is a good way to get high IO performance. The Golang way of doing it with normal, blocking libraries and Goroutine's see…
Callback hell isn't, but promises do help (to a point)
In 0.12, node will ship with a version of v8 which has generators (hidden under the --harmony flag), which are shallow coroutines, which allow for the same code style as go-routines.
Existing non-blocking libraries will be reusable with generators via e.g. https://github.com/jmar777/suspend or https://github.com/visionmedia/co etc.
Performance could also potentially improve as in V8 closures are much more expensive than generators.
Re: Explicit bootstrapping of pip in Python installations
#60Python packaging has been a nightmare compared to RubyGems (which is not without its own problems, of course). See for example this rant by a major Python developer: http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/
This sounds like a great step forward to me in making Python packages easy to create, install, and uninstall!