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

_osx_support.get_platform_osx() does not always return the minor release number #102362

Closed
keleftheriou opened this issue Mar 2, 2023 · 7 comments
Assignees
Labels
OS-mac type-bug An unexpected behavior, bug, or error

Comments

@keleftheriou
Copy link

keleftheriou commented Mar 2, 2023

_osx_support.get_platform_osx(), particularly when called from sysconfig.get_platform(), might not return the minor release number. This seems to be because the MACOSX_DEPLOYMENT_TARGET environment variable will be used instead (if present), which may or may not include a minor version number.

E.g. on macOS 12.6 with MACOSX_DEPLOYMENT_TARGET=12:

>>> _osx_support.get_platform_osx({}, "", "", "")
('macosx', '12.6', '')
>>> _osx_support.get_platform_osx(sysconfig.get_config_vars(), "", "", "")
('macosx', '12', '')

Perhaps release = macver could be switched to release = macrelease here so that the internal _get_system_version() will be used instead?

Linked PRs

@keleftheriou keleftheriou added the type-bug An unexpected behavior, bug, or error label Mar 2, 2023
@terryjreedy
Copy link
Member

terryjreedy commented Mar 2, 2023

It seems to me that TARGET without minor release suggests that minor release number is not relevant. I have no thought on the other case.

@keleftheriou
Copy link
Author

Agreed, it shouldn't be relevant. The reason I looked into this is because a wheel file I'm generating is producing this error: [REDACTED]_macosx_12_arm64.whl is not a supported wheel on this platform., and the filename is derived from sysconfig.get_platform().

If I manually rename it the file to add e.g. _0 after macosx_12 it works fine, and I was looking to identify the root cause of the issue. Perhaps always including a zero for the minor version returned from get_platform_osx() would be more consistent.

@ned-deily ned-deily self-assigned this Mar 2, 2023
@keleftheriou
Copy link
Author

May be related: pypa/wheel#385 (comment)

ronaldoussoren added a commit to ronaldoussoren/cpython that referenced this issue Dec 10, 2023
…platform()

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
@ronaldoussoren
Copy link
Contributor

ronaldoussoren commented Dec 10, 2023

I've added a PR that will add '.0' to the version when MACOSX_DEPLOYMENT_TARGET is set to just a major version.

The PR is labelled for back port to 3.11 and 3.12, but I'm not sure if this is a change that is suitable for back ports.

  • 👎/👍: This doesn't affect our installers at all as those get build with 10.9 as the deployment target
  • 👍: This fixes an inconsistency in the result from sysconfig.get_platform() w.r.t. expectations from pip/platform
  • 👎: The fix likely isn't necessary for build tooling because, in particular, the wheel project already contains a workaround for this
  • It is hard to gauge whether or not this negatively impact existing code (e.g. code that expects that the version exactly matches the deployment target).

@ronaldoussoren
Copy link
Contributor

@ned-deily, what's your opionion on this (both the change to make sure that the platform version includes at least a major and minor version and back porting this change)?

@ned-deily
Copy link
Member

I think this is a long-standing bug, ever since Apple changed the semantics of macOS release numbers with macOS 11, and this should be the least-disruptive fix for it. The only gotcha I can think of is if the standard lib _osx_support isn't being called, perhaps by a distutils replacement. We could consider in addition changing configure.ac to do something similar if MACOSX_DEPLOYMENT_TARGET defaults to only a major version, but not if explicitly set by a variable. Again, as far as backporting, perhaps just to 3.12 to start?

ned-deily pushed a commit that referenced this issue Dec 18, 2023
…rm() (GH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Dec 18, 2023
…platform() (pythonGH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
(cherry picked from commit 893c9cc)

Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Dec 18, 2023
…platform() (pythonGH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
(cherry picked from commit 893c9cc)

Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com>
ronaldoussoren added a commit that referenced this issue Dec 19, 2023
…_platform() (GH-112942) (#113264)

gh-102362: Fix macOS version number in result of sysconfig.get_platform() (GH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
(cherry picked from commit 893c9cc)

Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com>
@ronaldoussoren
Copy link
Contributor

I think this is a long-standing bug, ever since Apple changed the semantics of macOS release numbers with macOS 11, and this should be the least-disruptive fix for it. The only gotcha I can think of is if the standard lib _osx_support isn't being called, perhaps by a distutils replacement. We could consider in addition changing configure.ac to do something similar if MACOSX_DEPLOYMENT_TARGET defaults to only a major version, but not if explicitly set by a variable. Again, as far as backporting, perhaps just to 3.12 to start?

The public interface for this is sysconfig.get_platform(), anyone that calculates the platform on their own can adjust the version manually.

I'll merge the back port to 3.11 as well. The most because this fixes a bug: the result of sysconfig.get_platform() currently is not valid according to packaging when MACOSX_DEPLOYMENT_TARGET is set to a value with just a major version.

ronaldoussoren added a commit that referenced this issue Dec 19, 2023
…_platform() (GH-112942) (#113265)

gh-102362: Fix macOS version number in result of sysconfig.get_platform() (GH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
(cherry picked from commit 893c9cc)

Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com>
@keleftheriou keleftheriou changed the title _osx_support.get_platform_osx() sometimes does not return the minor release number _osx_support.get_platform_osx() does not always return the minor release number Dec 20, 2023
ryan-duve pushed a commit to ryan-duve/cpython that referenced this issue Dec 26, 2023
…platform() (pythonGH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
aisk pushed a commit to aisk/cpython that referenced this issue Feb 11, 2024
…platform() (pythonGH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
Glyphack pushed a commit to Glyphack/cpython that referenced this issue Sep 2, 2024
…platform() (pythonGH-112942)

Change _osx_support.get_platform_osx() to make sure that the
version number in the result includes at least a major and
minor version (e.g. 14.2) even if MACOSX_DEPLOYMENT_TARGET is
set to just a major version (e.g. 14).

This matches the versions expected by pip when selecting
appropriate wheels for installation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS-mac type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

4 participants