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 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.
Explicit bootstrapping of pip in Python installations
31–40 of 78 posts
Re: Explicit bootstrapping of pip in Python installations
#32Earlier 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.
Didn't come with it, or didn't install it by default?
In that the following commands have also been required after running pyvenv-3.3, no, python has not "come with" pip:
(venv) $ wget http://python-distribute.org/distribute_setup.py
(venv) $ python distribute_setup.py
(venv) $ easy_install pip
Re: Explicit bootstrapping of pip in Python installations
#33This 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)
Exactly! I am currently working on a machine learning task. Python is great for this, but most of the scripts that I am writing are run-once scripts. VirtualEnv would be overkill of this usecase.
Re: Explicit bootstrapping of pip in Python installations
#34Earlier quoted context omitted.
More importantly, it's nice to assume your users will have pip available no matter what (assuming we all move to Python 3. One day...)
As 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.
As 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.
Re: Explicit bootstrapping of pip in Python installations
#35Earlier quoted context omitted.
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)
> 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?
Libraries 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.
Re: Explicit bootstrapping of pip in Python installations
#36This 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'm not a web developer, but I do data analysis with Python, and I use virtualenv heavily. For one thing, it increases reproducibility to have a record (pip freeze) of which versions of each package I used.
Re: Explicit bootstrapping of pip in Python installations
#37Earlier quoted context omitted.
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)
> 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?
If 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.)
Re: Explicit bootstrapping of pip in Python installations
#38I 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.
Re: Explicit bootstrapping of pip in Python installations
#39I'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".
Re: Explicit bootstrapping of pip in Python installations
#40I 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.