PEP 514 introduced a registration mechanism for Windows, and is adopted by the official installers. This provides a nice unified way to discover Python installations1, and brought tools like the Python launcher (py.exe).
I’m wondering if it is a good idea to bring this to more platforms. Every Linux distribution has its own thing, but there is one easy target: macOS. CPython already distributes installers, and there is a clear canonical way to record things (the user defaults system). Would it make sense to have a similar registry for macOS, and potentially a launcher as well?
1 CPython, at least; are there other Python distributors adapting this yet?
I will mention in regards to the Python launcher for UNIX that I want to get it so there’s a single launcher for all platforms, so “potentially a launcher” should hopefully be just an update.
I also want to solve the registration issue on UNIX in general, so there’s the OS-specific solution (e.g. the registry on Windows), but there’s also using a generic config file solution ala XDG base directories if people want to go the more UNIX-y solution on macOS instead of the macOS-y solution.
Would Windows be included in the supported platforms? If that’s the case, an OS-specific storage may not be as much a problem, since PEP 582 is already non cross-platform (using the Windows registry).
That said, Python’s stdlib has winreg, but not a general way to interact with the defaults system (there is plistlib, but it does not know how to find plists), so maybe the defaults system is not the right storage. Maybe it is better to develop an INI-based format, and store them in common locations like used by appdirs? (Note that macOS does not conform to the XDG base directory spec.)
One reason to favour INI is it is already used by PEP 397 (launcher for Windows). I guess there is no reason to use TOML for the PEP 514 equivalent and INI for PEP 397 though. It is also possible to add TOML support alongside with INI for PEP 397 (I believe INI was originally chosen mainly because it Windows supports it natively1), although that sounds a bit messy to me.
1 Side note if we’re using Rust—A surveyed some INI libraries a while ago, and all existing Rust parsers use case sensitive keys, while the Windows API is case insensitive. This could cause some incompatibilities.
I haven’t thought through how much backwards-compatibility for PEP 397 will be necessary/desired as that PEP was not written with UNIX/xplat in mind. For instance I don’t like the PY_PYTHON env var scheme as no other Python-related env var has that sort of prefix.
But I’m not worrying about that yet until the launcher is ready for serious testing and talking about whether people want to adopt it.
This is a fundamental problem with the INI “format”, not with any one parser (or collection thereof). If you don’t write a specification for your file format, you can’t guarantee that the parsers for it will make the same design choices. This is a big argument against using INI for anything which will be read by more than one program: there’s no spec, so you can’t expect parser consistency. TOML is well-specified; it may have flaws for complex nested structures but in simple cases it’s just “better INI”.
It just seemed like something that seemed explainable to anyone.