Nice... 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.
Explicit bootstrapping of pip in Python installations
61–70 of 78 posts
Re: Explicit bootstrapping of pip in Python installations
#62Python 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!
Bundling 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.
Re: Explicit bootstrapping of pip in Python installations
#63I'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.
As 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".
I 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.
Re: Explicit bootstrapping of pip in Python installations
#64Earlier quoted context omitted.
As 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".
I 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…
Yeah 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.
Re: Explicit bootstrapping of pip in Python installations
#65I 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.
I 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?
Re: Explicit bootstrapping of pip in Python installations
#66Earlier quoted context omitted.
I have no idea how to get virtualenv working. I'm that user that needs it for now!
Install virtualenv: pip install virtualenv mkdir ~/.virtualenvs virtualenv ~/.virtualenvs/my_new_project Activate it to continue development: . ~/.virtualenvs/my_new_project/bin/activate The effect of this is that `python` and `pip` commands now only act on the virtualenv and not system (or user) site wide. Deactivate it: deactivate Python and pip commands are now the system versions again.
Craig, you're my internet hero today. Much thanks!
Re: Explicit bootstrapping of pip in Python installations
#67I 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…
> 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.
Re: Explicit bootstrapping of pip in Python installations
#68Python 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!
Bundling 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.
pip continues to improve and they are providing it outside the stdlib.
Re: Explicit bootstrapping of pip in Python installations
#69Earlier quoted context omitted.
Bundling 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.
pip continues to improve and they are providing it outside the stdlib.
They surely do... but at what pace?
Re: Explicit bootstrapping of pip in Python installations
#70Earlier quoted context omitted.
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.
I 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?
here are some wheel links:
https://pypi.python.org/pypi/wheel
https://wheel.readthedocs.org/en/latest/index.html
https://bitbucket.org/dholth/wheel/
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.