Don't break Python install path detection on Debian

[ferdnyc]

OK, this adds in this fix with the #222 changes, which should protect against #227

Python: Assume /usr/local prefix on Debian

If we're using the fallback path detection method on Debian, we
shouldn't compute the install path relative to ${CMAKE_INSTALL_PREFIX}
since it isn't. So, we assume it's relative to /usr/local instead.

[sparfenyuk]

I don't understand why it is so complicated? Can't we just use FIND_PACKAGE(Python 3)?

[ferdnyc]

@sparfenyuk

I don't understand why it is so complicated? Can't we just use FIND_PACKAGE(Python 3)?

That wouldn't give us the module install path.

We can't use find_package(Python3) anyway, because that didn't exist until CMake 3.12, and we need to support all the way down to CMake 3.1.

(The thing we are using, because it existed before CMake 3.12, is find_package(PythonLibs) and find_package(PythonInterp). Still has the same problem that it doesn't give us the install path, though, just points us to the interpreter executable and build tools.)

Really, it's only complicated because the Debian Python people are on crack.

[ferdnyc]

(TL;DR version of the linked comment:)

Debian-derived distros follow the Debian Python Policy which says that:

A special directory is dedicated to public Python modules installed by the local administrator, /usr/lib/python3/dist-packages for all Python 3 versions, /usr/local/lib/python2.Y/dist-packages for Python 2.6 and later, and /usr/local/lib/python2.Y/site-packages for Python 2.5 and earlier.

For a local installation by the administrator of Python 2.6 and later, a special directory is reserved to Python modules which should only be available to this Python, /usr/local/lib/python2.Y/site-packages (and /usr/local/lib/python3/site-packages for all Python 3 versions). Unfortunately, for Python 2.5 and earlier this directory is also visible to the system Python.

...But then their own distutils returns /usr/local/lib/python3/dist-packages as the module instal path for the default /usr/local/ prefix. You'll notice that directory is not even mentioned in the above quote. It's also not in the sys.path of the distro /usr/bin/python3.x interpreters! So if you were to install modules there, they would not be available without path modifications.

[jonoomph]

Thanks @ferdnyc! This looks all sorts of crazy (not blaming you, haha). But I'm feeling crazy, so let's give it a try. Hopefully one day someone will stop by and say, you guys are nuts, just use this 1 line solution, lol! 👍

[jonoomph]

Darn, all builders failed initially. Looks like Linux did work okay, with a minor tweak to the gitlab-ci.yml file (just a path changing), but Mac and Windows failed in a stranger way. Might be related to Cmake version, not sure. Details are included in #260.

[jonoomph]

Maybe we just go with the most "standard / simplest" approach, and let Debian patch things if they want to hard-code it, or use a different method? I can always make things work with respect to the builders... and distros can (and usually do) patch the Python install path.

[ferdnyc]

I hate this change. Or it hates me, not even sure which.

All I know is that the current bindings install-path logic is completely broken. The Python logic tries too hard to be too clever, and turns into a mess. Whereas the the Ruby bindings aren't nearly clever enough — if you build with a relative CMAKE_INSTALL_PREFIX, it will try to write into /usr/ on make install! That's just horrible.

I really want to fix that, still, but I feel like there are too many moving parts too far out of my reach to figure out how.