[superkuh]

On systems were you don't need to do this (new enough) it'll work. On systems where you need to do this it will break things. And because it's pip, it'll be incredibly hard to figure out what broke and how to fix it.

[geofft]

In general you can avoid pip breaking things by doing so inside a virtualenv. The following should work on at least the last few years' worth of OSes:

    $ virtualenv /tmp/ve
    $ /tmp/ve/bin/pip install -U pip setuptools
    $ /tmp/ve/bin/pip install cmake
    $ /tmp/ve/bin/cmake ...
    $ rm -rf /tmp/ve

On some OSes (e.g. Debian and derivatives) you'll need to install virtualenv itself from the OS first, but that won't break things because it's from the OS.

On sufficiently old OSes, you may need to set PIP_INDEX_URL=https://pypi.org/simple/ and PIP_TRUSTED_HOST="pypi.org files.pythonhosted.org" to disable certificate verification. (I'm not sure of a good way to work around this problem. In theory, Python 3 would solve it, but those same old OSes have an old enough Python 3 that the latest version of setuptools fails, and I can't figure out how to install an old enough setuptools.)

Also - if you need to unbreak your system Python, in general it suffices to ensure that /usr/local/lib and ~/.local/lib have no pythonX.Y directories with anything in them. (Empty directories are fine.) At my last job where we needed to give non-sysadmins root access on certain machines, I added a Nagios check to /usr/local/lib/python*, which was remarkably effective at catching problems before they turned inexplicable.