This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author siming85
Recipients dstufft, eric.araujo, siming85
Date 2017-08-15.16:20:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1502814030.02.0.254840991446.issue31211@psf.upfronthosting.co.za>
In-reply-to
Content
in CentOS installations where both 32 and 64 bit libraries can co exist, and when python is compiled to run with 32-bit libraries (i686)

>>> from distutils.util import get_platform
>>> get_platform()
'linux-x86_64'

because the api only looks at OS flavor and not the actual binary architecture.

this string is used as part of PEP425 tags in the built wheel/egg file:
my_package-3.3.0-cp34-cp34m-linux-x86_64.whl

but this creates a mismatch with PIP - pip.pep425tags returns "linux-i686" instead on the same python instance, addressed by:

# snippet pip code
def _is_running_32bit():
    return sys.maxsize == 2147483647
    
if result == "linux_x86_64" and _is_running_32bit():
    # 32 bit Python program (running on a 64 bit Linux): pip should only
    # install and run 32 bit compiled extensions in that case.
    result = "linux_i686"

so the end result is any packages built with sdist_wheel (using setuptools/distutils) is not installable on the same instance.

Of course the workaround is to overwrite that and provide --plat-name linux_i686. 

but the question is - shouldn't the tags line up?
History
Date User Action Args
2017-08-15 16:20:30siming85setrecipients: + siming85, eric.araujo, dstufft
2017-08-15 16:20:30siming85setmessageid: <1502814030.02.0.254840991446.issue31211@psf.upfronthosting.co.za>
2017-08-15 16:20:29siming85linkissue31211 messages
2017-08-15 16:20:29siming85create