verify installation of a dummy Python package before actually installing a Python package

[boegel]

After spending about 2h on trying to figure out why a particular setuptools installation was blatently ignoring --prefix, I was sufficiently frustrated to come up with this: a verification of whether whichever setuptools is active honors --prefix before actually installing a Python package with it.

Up until now, I've run into two different ways of making setuptools blatently ignore --prefix:

• via the distutils.cfg or $HOME/.pydistutils.cfg configuration files which effectively override any specified --prefix comand line option (cfr. https://docs.python.org/2/install/#distutils-configuration-files)
• by using a setuptools installation that was installed with --user into $HOME/.local, causing it to install everything to $HOME/.local regardless of what --prefix specifies (yes, you read that right)

Since there's little we can do to prevent the use of a (basically broken) setuptools installation (there's no way I'm aware of in which we can install our own and be 100% sure it'll be used), we better have a way of verifying whether the active setuptools does the right thing.

related: easybuilders/easybuild#31, #373 and last nights discussion with @kcgthb on the #easybuild IRC channel

@stdweird, @JensTimmerman: thoughts on this?

cc: @kcgthb, @chwilk, @DimitriSteyaert, @pforai, @ocaisa

[stdweird]

patch setuptools? (the one used is one EB installed right?)

[stdweird]

also, move in separate method

[stdweird]

define in the if block

[stdweird]

use filehandle, so you'll open it only once (and close it explicitly)
second, don't read in the whole file, use readline or eg first 4k bytes.
after the read and match if found, don't forget to fh.seek(0) before reading the whole script.
although i'd prefer fileinput thoe all this....

[boegel]

No longer relevant, so closing.

Let is serve as documentation on how setuptools can be a genuine PITA...