On Stack Overflow, a user asked, "Should python-dev be required to install pip"? I think the answer to that is no, at least the way things are split up on most distros today. But there's clearly a potential for confusion for new developers, as the OP pointed out in a comment.

On most linux distros, the python package (usually pre-installed) doesn't include Python.h and other files needed for development, which are split off into a package named something like python-dev or python-devel.

Meanwhile, there are distro packages for Python packages that go with that distro-installed Python. If you want numpy, or django, you use the distro's package manager to install python-numpy or python-django.

And for packages the distro doesn't have, there's always python-pip, which installs pip, so you can use pip to install additional packages.

The problem is that if you install python-pip, but not python-dev, you can't use pip for any packages that need to build C extension modules. Besides needing a compiler toolchain, for pip install lxml to work, you need to have first installed your distro's libxml2-dev package. And, unless pip is going to add hooks to work with distro packaging systems (in which case it probably shouldn't be installing anything in the first place, just creating distro packages to be installed), there's no way around that problem. Plus, making python-pip depend on python-dev would mean you could no longer use pip to install pure Python packages or binary wheels. And how would it work with virtual environments; would python-virtualenv also depend on python-dev?

So, it seems like a big mess…

But only if you're thinking in terms of today's distros, with Python 2.7 and pip 1.4 or earlier. Python 3.4, pip 1.5, and wheel make everything a lot different—and a lot simpler.

Python 3.4 comes with a pip bootstrap (see PEP 453 for details). The distros might decide to split that off into a separate package, but PEP 453 explicitly recommends against that (and was cowritten by the guy in charge of Python strategy for Red Hat).

Python 3.4 also comes with a built-in virtual environment tool, venv, which automatically installs pip into every virtual environment. And you can use venv as a deployment tool. And this will completely eliminate the problems—you won't want or need to use pip on your production machines.

Meanwhile, pip 1.5 has better integration with the wheel format and package (see PEP 427). If you need to use a package that your distro doesn't provide, and can't use a venv, you can build a wheel on your dev machine, host it on an in-house repo, and pip install it to your production machine without needing python-dev, or a compiler or libxml2-dev or anything of the sort.

So, the solution becomes very simple: Don't install python-dev on production machines; even if you're not using a venv, you won't be pip install-ing anything except off an internal repo. Install python-dev on all other machines, so you can pip install off PyPI.

What about Python 2.7? Well, it's not perfect. That's why we have 3.2, 3.3, 3.4, and other new versions of Python. It's too late to fix 2.7. Red Hat or Ubuntu might come up with their own solution (it wouldn't be that hard to preinstall pip and virtualenv…), but Python isn't going to.