trove-classifiers icon indicating copy to clipboard operation
trove-classifiers copied to clipboard
verified publisher icon pypa

macOS classifiers are somewhat outdated and non-specific

Open glyph opened this issue 1 year ago • 1 comments

Windows looks like this:

    "Operating System :: Microsoft :: Windows",
    "Operating System :: Microsoft :: Windows :: Windows 3.1 or Earlier",
    "Operating System :: Microsoft :: Windows :: Windows 7",
    "Operating System :: Microsoft :: Windows :: Windows 8",
    "Operating System :: Microsoft :: Windows :: Windows 8.1",
    "Operating System :: Microsoft :: Windows :: Windows 10",
    "Operating System :: Microsoft :: Windows :: Windows 11",
    "Operating System :: Microsoft :: Windows :: Windows 95/98/2000",
    "Operating System :: Microsoft :: Windows :: Windows CE",
    "Operating System :: Microsoft :: Windows :: Windows NT/2000",
    "Operating System :: Microsoft :: Windows :: Windows Server 2003",
    "Operating System :: Microsoft :: Windows :: Windows Server 2008",
    "Operating System :: Microsoft :: Windows :: Windows Vista",
    "Operating System :: Microsoft :: Windows :: Windows XP",

whereas macOS looks like this:

    "Operating System :: MacOS",
    "Operating System :: MacOS :: MacOS 9",
    "Operating System :: MacOS :: MacOS X",
    "Environment :: MacOS X",
    "Environment :: MacOS X :: Aqua",
    "Environment :: MacOS X :: Carbon",
    "Environment :: MacOS X :: Cocoa",

It's not clear to me why Environment exists for macOS and not Windows, nor why every major release of Windows gets a new classifier but no release of macOS for the last 20 years has a new one.

Also, for the last 8 years or so, "macOS" is the correct style.

It's not clear that there are a lot of Python packages that need to target precise macOS versions but it seems like this should be symmetrical just for aesthetic reasons?

I'm not sure what exact list to propose though. Is there any guidance for the structure of new classifiers? Is it important to maintain compatibility with the old hierarchy? Does case matter?

glyph avatar Feb 08 '24 19:02 glyph

I think this should be brought up on discuss.python.org, so that the CPython Mac experts and the packaging folks can see it.

merwok avatar Mar 21 '25 16:03 merwok

Aqua/Carbon/Cocoa were widget frameworks with very specific characteristics and weren't particularly compatible with each other.

I think in modern times people would use Quartz ~ Core Graphics instead of any of those.

The old hierarchy is sufficiently crufty that I'd really love to encourage it to be killed.

I came here to file a simpler version of this bug to just complain about MacOS X, which was never correct. The original OS was Mac OS X Server 1.0 (released 1999) and as of macOS 10.12 (September 2016), it's still wrong. There's an article macOS version history with the details.

My guess is that people gave up on the classifiers. There are fewer than 9 full pages of Environment :: MacOS X :: Cocoa vs almost 243 for Operating System :: MacOS.

I know a number of entities have filled in Operating System :: MacOS instead of Operating System :: MacOS :: MacOS X (the project I'm currently examining did that). At this point, pretending that MacOS and macOS are compatible is misleading. An app built for MacOS would run on m68k or ppc (if fat, both). Mac OS X 10.6 released in 2009 and dead by 2013 was the last modern OS to support powerpc hardware. "Support for Rosetta was dropped with Mac OS X Lion (10.7) in 2011." So, no modern mac is going to run a Mac Classic app.

The simplest thing thus is to split Mac OS (Classic) from macOS (modern) and acknowledge that they're distinct. Encourage new apps to list as Operating System :: macOS (unless they're really legacy apps).

The first app I looked at was: https://pypi.org/project/aesir/

It claims to be for Mac OS 9. It purports to be a bitcoin client. No one in their right mind would run that on Mac OS 9. (I wouldn't trust this app in the first place, so perhaps the fact that it includes the Mac OS 9 classifier is a blessing.)

jsoref avatar Jun 17 '25 01:06 jsoref

Aqua/Carbon/Cocoa were widget frameworks with very specific characteristics and weren't particularly compatible with each other.

I think in modern times people would use Quartz ~ Core Graphics instead of any of those.

This is … not accurate at all. What follows may be somewhat nitpicky but I feel like we should all proceed from a factual basis as we re-engineer the classifiers. Mostly I agree that they were never really suitable and are even less suitable today but I still think that having a correct understanding of why that is the case is important.

Technically speaking “Aqua” is the visual layer in macOS, and has continuously referred to “whatever macOS looks like” since Mac OS X was first released. It is rarely used in branding nowadays because it is associated in the popular imagination with the garish blue glass buttons and weird “ruled white paper” aesthetic of the early releases. But “Aqua” is still the thing AppKit draws today.

Carbon was a legacy compatibility wrapper that was largely source-compatible (but, notably, not binary-compatible) with MacOS 9, designed to ease the transition between classic MacOS and MacOS X.

Cocoa is a general name referring to the core frameworks on modern macOS, including Foundation (which does basic data structures and other things), AppKit (the “widget toolkit”, I guess, although it does a lot more than drawing UI on the screen) and CoreData.

In general, Cocoa does not get used much as a label any more either, because there are dozens of other frameworks (not under the “cocoa” umbrella) involved in macOS these days, and many mac developers are interested in apple’s other platforms, so they may be using SwiftUI, which, while it layers over AppKit on macOS, it used UIKit on other platforms. But there is still cery much a Cocoa.h that is included by a bazillion programs.

Quartz and CoreGraphics are roughly synonymous (although the “Quartz” branding is used as an adjective on just about everything the mac does related to graphics), and were the original as well as the current primitives used for AppKit on MacOS X / macOS. You would use these if you were interested in drawing every pixel of your own widgets by hand with no help from the operating system’s libraries, but not otherwise.

glyph avatar Jun 17 '25 03:06 glyph

I came here to file a simpler version of this bug to just complain about MacOS X, which was never correct. The original OS was Mac OS X Server 1.0 (released 1999) and as of macOS 10.12 (September 2016), it's still wrong. There's an article macOS version history with the details.

~~Also I feel like I should note here that it was not "never" correct.~~

(Oh, I see what you're saying, it should be "Mac OS X" not "MacOS X")

~~It~~ "Mac OS X" was correct from 1999 to 2011, then "OS X" was correct from 2012 to 2015. From 2016 onward, so nearly a decade now, "macOS" has been correct, but due to the vast amount of software with an identifier such as osx baked into it (for example, the wheel tag macosx), things have been extremely slow to change.

"Mac OS X Server 1.0" was a bizarre historical aberration that was a sort of half-functional preview of what the NeXTSTEP-derived parts of the initial version of Mac OS X would be, not really a full version of the OS that would come out for consumers. It looked extremely weird — basically a hodgepodge of Mac OS 8 and NeXTSTEP — and not much software was ported to it.

glyph avatar Jun 17 '25 04:06 glyph

The simplest thing thus is to split Mac OS (Classic) from macOS (modern) and acknowledge that they're distinct. Encourage new apps to list as Operating System :: macOS (unless they're really legacy apps).

The taxonomist and preservationist in me wants to faithfully represent every possible classic flavor of classic Mac OS in this taxonomy but I think there is an element of realpolitik here, which is that PyPI has never been accessible by classic Mac OS. The last version of Python I can find for classic MacOS that is even available on archive.org is Python 2.3.3; in order to get it to even run, I had to manually apply a "CarbonLib" update to my classic PPC mac environment. It does not come with setuptools, it does not have an SSL module at all; no version of Python exists for this platform that could even parse a wheel, let alone download one.

So, my proposal would be: deprecate all the existing tags, and simply add:

Operating System :: Apple :: macOS
Operating System :: Apple :: iOS
Operating System :: Apple :: iPadOS
Operating System :: Apple :: tvOS

To mirror the Microsoft hierarchy and to make a clean break that indicates a correctly-designed hierarchy that can be used going forward. Possibly with exact :: 15 :: 15.5 sub-classifiers although those should probably be discouraged except in hyper-specific circumstances.

glyph avatar Jun 17 '25 04:06 glyph

It does not come with setuptools

No version of Python does 😌

(probably you meant ensurepip and/or venv that allows one to get setuptools or other build backends – but this thread is about exactness)

merwok avatar Jun 17 '25 14:06 merwok

Do you want to post to https://discuss.python.org/ as suggested by @merwok ?

Fwiw, it looks like the current mess came from https://peps.python.org/pep-0301/

jsoref avatar Jun 18 '25 11:06 jsoref