Bug 1426435

Summary: distutils.sysconfig.get_python_lib() return /usr/local/..../site-packages
Product: [Fedora] Fedora Reporter: Igor Gnatenko <ignatenko>
Component: python3Assignee: Michal Cyprian <mcyprian>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 26CC: awilliam, bkabrda, cstratak, ishcherb, mcyprian, mhroncok, mkolman, pbrobinson, pviktori, rkuska, tomspur, torsava
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-10 09:41:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1425827    

Description Igor Gnatenko 2017-02-23 22:15:51 UTC
It's unacceptable, because it breaks all builds which use standard CMake module which relies on that function which means DNF, libsolv, libdnf is just FTBFS now on.

Comment 1 Igor Gnatenko 2017-02-23 22:22:01 UTC
$ python3 -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(True))"
/usr/local/lib64/python3.6/site-packages

Comment 2 Igor Gnatenko 2017-02-23 22:27:14 UTC
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

Comment 3 Michal Cyprian 2017-02-24 10:12:28 UTC
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.

Comment 4 Igor Gnatenko 2017-02-24 10:19:44 UTC
(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.

Comment 5 Martin Kolman 2017-02-24 12:54:26 UTC
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.

Comment 6 Adam Williamson 2017-02-24 16:21:13 UTC
For the record - the fact that this blocks 1425827 means it's blocking the Fedora 26 Alpha release.

Comment 7 Charalampos Stratakis 2017-02-24 16:30:33 UTC
The change has been reverted for the time being.

Comment 8 Fedora End Of Life 2017-02-28 12:25:40 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 9 Michal Cyprian 2017-04-10 09:41:50 UTC
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