34 ms·
Explicit bootstrapping of pip in Python installations
- dave809 13y agoNifty, always nice to save a little time on future installs
- babarock 13y agoMore importantly, it's nice to assume your users will have pip available no matter what (assuming we all move to Python 3. One day...)
- Walkman 13y agoPython 3.4 seems it will be true to it's promise. See the other thread: https://news.ycombinator.com/item?id=6581053 https://news.ycombinator.com/item?id=6581053
- jiaaro 13y agoAs someone maintaining packages on pypi, I can tell you that demand for Python 3 support is growing and people are beginning to port packages for their own needs. I expect we'll see python 3 overtake python 2 in new projects within 3 years. I realize that's still pretty far off, but these things take time. You have to give the PSF credit for great support of the 2.x series.
- ConceptJunkie 13y agoAs a recent convert to Python (but only as an enthusiast... still doing C++ in my dayjob), I chose to go all in and start out with Python 3. I'm glad I did, but I do need to keep version 2 around.
- thearn4 13y agoGood to hear. The situation with python packaging has seemed kind of chaotic for awhile. The setuptools/distribute merger will hopefully standardize things from here on out.
- oddshocks 13y agoGlorious day! As a person who went to PyCon and experienced first-hand the state of Python packaging, this is excellent news. Good luck to the Python devs in the days to come.
- wslh 13y agoYes! and with pip you can uninstall packages while with easy_install you can't
- imsofuture 13y agoExcept for when uninstall doesn't work. Which is often.
- oddshocks 13y agoYep! I haven't used easy_install in a long time, but that is true!
- josteink 13y agoI'm not really a pythonist so I'm not 100% aware of the consequences of this, but as someone who deploys Python-based software every now and then, this just seems to make sense to me. About time really.
- jessaustin 13y agoAs indicated in the Tagliamonte piece linked above, be careful deploying with pip. OS or distro tools such as apt-get are usually more appropriate for deployment. Distro maintainers have made commitments that PyPI uploaders have not made. Of course sometimes users need things that are not available from a distro repo, but in that case they're not so much "users" as "testers".
- sitkack 13y agoI really really despise what distro maintainers do with packages. Pinning some stuff way in the past, esp deps used by lots of projects, this then forces consumers of those deps to get patches against their code to work causing a schizm in the public version and the distro version of the library. A huge pointless wasted mess. I almost always use pip and my own installed code (kinda homebrew like) to put dependencies onto a box. It takes more work but I can skip the bullshit.
- jessaustin 13y agoYeah I get that. If it's a frequently updated package that you use frequently and care about, or on an instance you're both developing and maintaining, it's totally worth it to do the system integration for yourself. I got the impression that GGP was deploying for other people. In that situation, not having a distro package maintainer for a package might mean the sysadmin becomes a de facto package maintainer, which sucks for the sysadmin and the users both.
- arturadib 13y agoLook at the trails Node + NPM have blazed. That's the right move. Next up: Local package installs.
- dangerlibrary 13y agoI don't think effective package management solutions were really pioneered by node and NPM. You could pretty easily re-write your comment and say "Look at the trails Debian + apt have blazed. That's the right move."
- knappe 13y agoOr, for a more apt (heh) comparison: https://github.com/rubygems/rubygems https://github.com/rubygems/rubygems
- jjwiseman 13y ago"If you are writing a package manager for a new non-js language, do whatever it takes to get that new language to load modules the way node does. The right way." http://dominictarr.com/post/25516279897/why-you-should-never-write-a-package-manager http://dominictarr.com/post/25516279897/why-you-should-never... http://dontkry.com/posts/code/modules-the-right-way.html http://dontkry.com/posts/code/modules-the-right-way.html To be more specific, what npm does that pip, debian, and rubygems don't do is nested dependencies, which is a wonderful advancement.
- mbreese 13y agoIsn't virtualenv going to be bundled too?
- tbatterii 13y agoa flavor of virtualenv was bundled in 3.3 (http://www.python.org/download/releases/3.3.0/ http://www.python.org/download/releases/3.3.0/) but without pip or easy_install it was a pretty useless feature IMO.
- riffraff 13y ago
- cjbprime 13y agoThis 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!
- TylerE 13y agoWe'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)
- Shish2k 13y agoHaving tried various ways of distributing desktop apps / non-web daemons, I've found virtualenvs useful there too (with the one fairly large caveat that installing wxWidgets in a virtualenv is a world of pain :( But then in those cases I use the OS-provided packages with the OS package manager, so I still never use virtualenv and pip independently)
- cjbprime 13y ago> We're not all building web apps in python - virtualenv is not universally useful. Huh, fair enough. I work on non-webapps too -- could you explain more about your use case?
- TylerE 13y agoLibraries that are very build-finicky (like various image processing libs) I've had bad luck with virtualenv, or env pip. Usually end up building by hand.
- stdbrouw 13y agoIf you're doing data analysis, where most libraries are serious about backwards compatibility and you don't necessarily care whether your code still runs two years from now... virtualenvs are sometimes just not worth the bother. (Though I'd still recommend them.)
- 13y ago
- babarock 13y agoVaguely related, this wonderful article by Paul Tagliamonte on how pip coexists with distro package managers (in this case APT): http://notes.pault.ag/debian-python/ http://notes.pault.ag/debian-python/ Nice reminder that pip is a dev tool and should be used as such. It makes sense to be included in Python.
- voltagex_ 13y agoI think that everywhere someone's instructed to use pip, it really should be to set up a virtualenv and then use pip inside that. pip should not be going anywhere near your site-packages, and it'd be great to be able to disable that ability.
- bbernoulli 13y agoI 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.
- orf 13y agoNot being able to install from binary installers is so annoying, it's a real shame it doesn't support it. Its the only reason I keep easy_install around.
- pekk 13y agoThis 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.
- tbatterii 13y agoI don't know much about the wheel format. But eggs being dead is news to me. You have links for those interested in more info?
- shoo 13y agohere are some wheel links: https://pypi.python.org/pypi/wheel https://pypi.python.org/pypi/wheel https://wheel.readthedocs.org/en/latest/index.html https://wheel.readthedocs.org/en/latest/index.html https://bitbucket.org/dholth/wheel/ https://bitbucket.org/dholth/wheel/ http://www.python.org/dev/peps/pep-0427/ http://www.python.org/dev/peps/pep-0427/ i am using wheel (with pip) as a replacement for .exe installers to install some packages (numpy, scipy, py2exe, etc) on windows. i find it useful because you can automate the installation of a wheel archive using pip (with the typical .exe windows installers you need to click next several times...). the wheel command line utility also knows how to convert existing `.exe` installers to wheel archives.
- 13y ago
- shadowmint 13y agoI 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 agoYa, this is a good thing. Ruby started shipping with rubygems since 1.9 and it's worked great.
- cls59 13y agoAnd Node started shipping NPM in 0.6.3 --- which has also worked great.
- tsurantino 13y agoIs 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 agoThe 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.
- jdp 13y agoHopefully 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 commit that fixed a bug in the PyPI 1.0.0 package whose version is still reported as 1.0.0 in setup.py at the commit. Then you freeze the environment to requirements.txt to distribute. It's still reported as package==1.0.0 instead of the git spec, so the next person to install will pull down the broken version from PyPI instead. The other headache is that installing from a requirements file just installs dependencies in the order they're listed, so oftentimes you need to re-organize the output of `pip freeze` to make sure dependencies are installed in the right order, otherwise you can encounter things like unexpected package versions due to other packages making ambiguous dependency specs for dependencies of your own app.
- pekk 13y agoI 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?
- jdp 13y agoYou'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.
- rfv 13y agoYey!
- unoti 13y agoFor 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?
- mayhew 13y agoI 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.
- spion 13y agoCallback 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 https://github.com/jmar777/suspend or https://github.com/visionmedia/co https://github.com/visionmedia/co etc. Performance could also potentially improve as in V8 closures are much more expensive than generators.
- 100k 13y agoPython 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/ 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!
- kolev 13y agoBundling the subpar pip actually solidifies the status quo and is in no way improving the situation. I think what made both Ruby and Node.js great is the flexible package management.
- mixmastamyk 13y agopip continues to improve and they are providing it outside the stdlib.
- kolev 13y agoThey surely do... but at what pace?
- kolev 13y agoNice... although I don't get why pip is so much behind RubyGems and NPM in terms of package management. pip should merge with virtualenv and virtualenvwrapper as well.