Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python generators: Use nonstandardlib for purelib definition #483

Merged

Conversation

hroncok
Copy link
Contributor

@hroncok hroncok commented Jul 28, 2018

The purelib and platlib were both defined to /usr/lib64/python on 64bits systems. This is because:

>>> get_python_lib(standard_lib=1, plat_specific=0)
'/usr/lib64/python3.7'

>>> get_python_lib(standard_lib=1, plat_specific=1)
'/usr/lib64/python3.7'

>>> get_python_lib(standard_lib=0, plat_specific=0)
'/usr/lib/python3.7/site-packages'

>>> get_python_lib(standard_lib=0, plat_specific=1)
'/usr/lib64/python3.7/site-packages'

So now we use standard_lib=0 to get the site-packages base path from /usr/lib and not /usr/lib64.

See https://bugzilla.redhat.com/show_bug.cgi?id=1609492

And https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/2

The purelib and platlib were both defined to /usr/lib64/python on
64bits systems. This is because:

    >>> get_python_lib(standard_lib=1, plat_specific=0)
    '/usr/lib64/python3.7'

    >>> get_python_lib(standard_lib=1, plat_specific=1)
    '/usr/lib64/python3.7'

    >>> get_python_lib(standard_lib=0, plat_specific=0)
    '/usr/lib/python3.7/site-packages'

    >>> get_python_lib(standard_lib=0, plat_specific=1)
    '/usr/lib64/python3.7/site-packages'

So now we use standard_lib=0 to get the site-packages base path
from /usr/lib and not /usr/lib64.
@Conan-Kudo
Copy link
Member

@hroncok This change looks good to me, but I'm actually a bit confused, what's the difference here between standard_lib=1 and standard_lib=0?

@Conan-Kudo
Copy link
Member

@hroncok Also, how does this affect Python 2?

@hroncok
Copy link
Contributor Author

hroncok commented Jul 28, 2018

One has site-packages and zero does not. Yet all standard library is in lib64, hence this results.

Will check legacy Python as well.

@hroncok
Copy link
Contributor Author

hroncok commented Jul 28, 2018

$ python2.7
Python 2.7.15 (default, May 16 2018, 17:50:09) 
[GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.sysconfig import get_python_lib
>>> from sys import version
>>> get_python_lib(standard_lib=1, plat_specific=0)
'/usr/lib64/python2.7'
>>> get_python_lib(standard_lib=1, plat_specific=1)
'/usr/lib64/python2.7'
>>> get_python_lib(standard_lib=0, plat_specific=0)
'/usr/lib/python2.7/site-packages'
>>> get_python_lib(standard_lib=0, plat_specific=1)
'/usr/lib64/python2.7/site-packages'

@Conan-Kudo
Copy link
Member

Then it still looks good to me. 👍

@ignatenkobrain ignatenkobrain merged commit fc449e0 into rpm-software-management:master Jul 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants