$ python3 -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(True))"
/usr/local/lib64/python3.6/site-packages

mcyprian (IRC)
IgorGnatenko[m]: if it is used in SPEC file %__python3 -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(True))" will return /usr/li64/.. am I right??
Igor Gnatenko
yes, just because %__python3 is system-python
but cmake doesn't know anything about system-python
bindings/python/CMakeLists.txt:EXECUTE_PROCESS(COMMAND ${PYTHON_EXECUTABLE} -c "from sys import stdout; from distutils import sysconfig; stdout.write(sysconfig.get_python_lib(True))" OUTPUT_VARIABLE PYTHON_INSTALL_DIR)
and PYTHON_EXECUTABLE is found by CMake's FindPython.cmake

Thanks for reporting this. Adding -DPYTHON_EXECUTABLE:FILEPATH=%{__python3} option to cmake command (%cmake .. -DPYTHON_DESIRED:str=3 -DPYTHON_EXECUTABLE:FILEPATH=%{__python3} -DWITH_MAN=0 in case of dnf) should fix it for now. 

We will announce some %py3_cmake_build macro for this use case soon and we will try to convince maintainers of all python3 packages using cmake tool to switch to new macro.

(In reply to Michal Cyprian from comment #3)
> Thanks for reporting this. Adding -DPYTHON_EXECUTABLE:FILEPATH=%{__python3}
> option to cmake command (%cmake .. -DPYTHON_DESIRED:str=3
> -DPYTHON_EXECUTABLE:FILEPATH=%{__python3} -DWITH_MAN=0 in case of dnf)
> should fix it for now. 
That's just workaround which would work only for dnf stack. There are many packages which hardcode python3 -c "..." call.
> 
> We will announce some %py3_cmake_build macro for this use case soon and we
> will try to convince maintainers of all python3 packages using cmake tool to
> switch to new macro.
Please don't. It's default CMake's behavior of FindPython.cmake. If you want to patch, patch cmake itself.

There is same situation with autoconf (the ax_python stuff), many other buildsystems/scripts rely on this behavior.

Looks like this is causing bug 1425827, as Anaconda uses get_python_lib() when looking for install classes (and for other things like updates image setup & dependency generation for the Anaconda dracut modules).

So this effectively breaks Anaconda and thus Fedora installation in Rawhide.

For the record - the fact that this blocks 1425827 means it's blocking the Fedora 26 Alpha release.

The change has been reverted for the time being.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

The patch responsible for this change of behavior was permanently reverted
[0]. The Fedora Change [1] was postponed for F27 and its implementation will be different to prevent similar issues.

[0] http://pkgs.fedoraproject.org/cgit/rpms/python3.git/commit/?id=bbccd649abc2d4cd646b9cc2c0889e3bd897e501

[1] https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe?rd=User:Torsava/Making_sudo_pip_safe