[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

[Steve Dower]

Steve Dower  added the comment:

Distutils is now deprecated (see PEP 632) and all tagged issues are being 
closed. From now until removal, only release blocking issues will be considered 
for distutils.

If this issue does not relate to distutils, please remove the component and 
reopen it. If you believe it still requires a fix, most likely the issue should 
be re-reported at https://github.com/pypa/setuptools

--
nosy: +steve.dower
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

[Éric Araujo]

Éric Araujo added the comment:

> both wheel/pip makes calls to distutils.util.get_platform(). Fixing it in one 
> location
> would fix it across the board.

True, but it may have unintended effects in other places that disrupt or break 
parts of the CPython build process, or downstream packaging toolchains.

> using just distutils.core.setup() and doing a bdist (built-in command 
> available in
> distutils) is still generating a wrong tag in linux 32-bit arch.

I would say that this is irrelevant, since these kinds of bdist are not well 
defined and not really used.

> within distutils.util.get_platform() the code under sunos makes attempts to 
> identify the > correct bitness: [...]
> why would the linux logic not handle the same problem?

That’s always the question with distutils, and the reason for us being 
over-cautious with these requests for changes.  One needs to do VCS archaeology 
to understand if a specific line was a conscious decision, an assumption, an 
oversight or a mistake.  My suggestion of bringing this to setuptools is 
because they have a much faster release cycle, and broad testing.  They can 
change only the wheel compatibility tags and get feedback immediately, whereas 
changing distutils.util.get_plaform may break many things and we’ll only know 
in a couple years when the next release is packaged by distributions and 
third-party vendors.

[removing Raymond from nosy and adding Jason the setuptools maintainer]

--
nosy: +jason.coombs -rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

[Siming Yuan]

Changes by Siming Yuan :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

[Siming Yuan]

Siming Yuan added the comment:

Hi Eric

I understand where you are coming from, but I disagree with having to raise 
this to 3rd party tools.

both wheel/pip makes calls to distutils.util.get_platform(). Fixing it in one 
location would fix it across the board.

In addition, taking setuptools & pip out of picture (uninstalling), using just 
distutils.core.setup() and doing a bdist (built-in command available in 
distutils) is still generating a wrong tag in linux 32-bit arch.

pkg-1.0.0.linux-x86_64.tar.gz

within distutils.util.get_platform() the code under sunos makes attempts to 
identify the correct bitness:
bitness = {2147483647:"32bit", 9223372036854775807:"64bit"}
machine += ".%s" % bitness[sys.maxsize]

why would the linux logic not handle the same problem?

--
resolution: third party -> 
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

[Éric Araujo]

Éric Araujo added the comment:

Hello!  Your analysis sounds right, but this is the wrong place.  distutils 
doesn’t know about wheels, it’s setuptools and/or the wheel module that 
generate them, and pip and others who consumes them.  Please report the issue 
to the setuptools and/or wheel bug trackers (see 
https://packaging.python.org/key_projects/ ) and I’ll close this one.

--
resolution:  -> third party
status: open -> pending
versions:  -Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31211] distutils/util.py get_platform() does not identify linux-i686 platforms

[Siming Yuan]

New submission from Siming Yuan:

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?

--
components: Distutils
messages: 300300
nosy: dstufft, merwok, siming85
priority: normal
severity: normal
status: open
title: distutils/util.py get_platform() does not identify linux-i686 platforms
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com