the _sysconfigdata name should not encode MACHDEP and PLATFORM_TRIPLET

[doko42]

BPO	37561
Nosy	@doko42

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-07-11.10:30:50.592>
labels = ['3.8']
title = 'the _sysconfigdata name should not encode MACHDEP and PLATFORM_TRIPLET'
updated_at = <Date 2019-07-11.10:30:50.592>
user = 'https://github.com/doko42'

bugs.python.org fields:

activity = <Date 2019-07-11.10:30:50.592>
actor = 'doko'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2019-07-11.10:30:50.592>
creator = 'doko'
dependencies = []
files = []
hgrepos = []
issue_num = 37561
keywords = []
message_count = 1.0
messages = ['347670']
nosy_count = 1.0
nosy_names = ['doko']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue37561'
versions = ['Python 3.8']

Linked PRs

• gh-81742 Omit platform from _sysconfigdata filename for multiarch #122879

[doko42]

so bpo-28046 decided to encode both MACHDEP and PLATFORM_TRIPLET/MULTIARCH in the _sysconfigdata name. Unfortunately on KFreeBSD MACHDEP includes the kernel version, so you end up with a changing MACHDEP. The _sysconfigdata name should only encode the MULTIARCH triplet, and if that's not define, the MACHDEP. Working on a fix.

[freakboy3742]

Following the discussion on #122879, it appears that:

1. The original motivation for this change no longer exists in Debian, as the kFreeBSD port no longer exists
2. Even if it did, the better fix is likely to make sys.platform for FreeBSD-alikes to be freebsd, rather than including the kernel version. This is analogous to the normalisation of linux2->linux as the sys.platform identifier for Linux builds.

On that basis, the best argument for this change is the multiarch-triplet is a more specific description of the platform than the platform name; but implementing the change would be disruptive to any code expecting the current format of the module name. Since we don't really gain anything from the disruptive change, I don't think this is worth the disruption.

I'm going to close this ticket on that basis; however, if anyone disagrees, I'd recommend starting a discussion on https://discuss.python.org.