Repository navigation
Support for Windows and Mac OS. #177
Description
Brought this up in Gitter and apparently this has had work done on it in a separate branch. (Link that here?). I've had multiple times where I wanted to have the amount of information about a Windows or Mac OS platform as the distro module gives but platform.mac_ver and platform.win32_ver are pretty deficient in. This thread is mostly for discussing how this would be done. cc: @nir0s
Activity
nir0s commentedon Apr 2, 2017
So, My idea was that we implement a class per OS type. Distro will identify the OS it's running on (Darwin, nt, linux, etc..) and generate a
distroobject for that OS type when it is imported.When you run
distro.id(), for example, it would map what would be the ID in Windows to the relevant information provided by the OS.This will aid users is making OS dependent decisions without having to know which OS they're running on.
nir0s commentedon Apr 4, 2017
That being said, this means that to keep a consistent API as well have to come up with a good mapping from each OS type to the names of the functions already in distro.
sethmlarson commentedon Apr 4, 2017
I would suggest changing
linux_distribution()to justdistribution()? The rest map pretty well actually. All Windows and Mac distributions have a codename, id='windows', 'macos', version, name, pretty name.nir0s commentedon Apr 5, 2017
distro.linux_distributionis meant to replaceplatform.linux_distribution.. so I think it's kinda weird to remove it now, though there's no problem with deprecating it at some point.If we want
distribution, I'd add it on top oflinux_distributionwhilelinux_distributiononly returns for linux anddistributionreturns for any.sethmlarson commentedon Apr 5, 2017
I'd say that something like that would work fine. Do we only define that method when on Linux (forcing
distrousers to check withhasattr) or havelinux_distributionthrow an error on non-Linux (forcingdistrousers to catch or check the system type first) or maplinux_distributiontodistributionjust for backwards-compatibilities sake? Kind of awkward name-wise but at least our users don't have to check anything or receive any unexpected exceptions. Number 1 and 3 seem like the best options IMO.nir0s commentedon Apr 8, 2017
Um, it seems more natural to me to return empty for
linux_distributionif you're not on linux and maybe throw a warning. Mapping might create some ambiguity since you're getting information on a non-linux system in what you'd expect to work only on linux. The reason because of which I like the return empty thing, is because distro tends to return (much likeplatform's implementation) empty results when it can't find something. This behavior would correspond with the natural flow distro's takes instead of unexpectedly erroring out only in this specific use case.sethmlarson commentedon Apr 8, 2017
Oh sure! That can definitely be done. So just a
Distributionobject that has all empty values.FooBarQuaxx commentedon Jan 2, 2019
This feature is very useful but I don't see any progress? The referenced @sethmlarson closed PR looks a good place to start (resume) work. I don't see why it's taking this long to deliver support for Windows and MacOS systems.
sethmlarson commentedon Jan 2, 2019
@FooBarQuaxx Changes to open source projects require contributors willing to give to their free time. Perhaps you could provide a patch?
Akm0d commentedon Oct 10, 2019
It might be helpful to use https://github.com/saltstack/salt/blob/master/salt/grains/core.py#L1624 as a reference when adding this feature
s0undt3ch commentedon May 17, 2020
@Akm0d where you referring to this?
Linked to a commit Sha so we would loose track of what implementation detail you were referring to.
i2 commentedon Jun 19, 2022
I was wondering if there is any update on this? Thank you!
ssbarnea commentedon Jan 10, 2023
@sethmlarson How open are you to welcome new cores to the project? I could give a hand with maintenance and also address long missing features like this one.
3 remaining items
Add reference to python-distro/distro#177
i2 commentedon Sep 5, 2024
@kdeldycke Are you going to ask for a merge of these features into upstream?
kdeldycke commentedon Sep 5, 2024
@i2 I don't know. Maybe my new features are too ambitious for the stated scope of
distro, which seems to be limited to filling the gap of the missing Python's originalplatform.linux_distribution.i2 commentedon Sep 5, 2024
@kdeldycke IMHO, it's worth trying... nothing to lose! I'd contact them (if possible) first before PR. Sometimes that helps!
Add detection of all macOS versions
webknjaz commentedon Mar 25, 2025
FTR, implementing this would also help the
bindepproject: https://storyboard.openstack.org/#!/story/2011141.webknjaz commentedon Feb 26, 2026
@kdeldycke wonder if your lib could monkey-patch this one maybe or be used in place of
distroinbindep.. Have you looked into this? (I'm occasionally wanting to resurrect https://github.com/marketplace/actions/bindep)@nir0s have you considered moving this into @jazzband, perhaps?Jazzband is shutting down so it'd need to be a different shared org.kdeldycke commentedon Feb 28, 2026
As of v10.0.0 (published today) my Extra Platforms project is no longer depending on
distro. Now that I am free ofdistrolegacy, we can go crazy and implement stuff there. Feel free to propose a feature request at https://github.com/kdeldycke/extra-platforms/issues !As for
bindep, if I understand correctly, it is a tool to detect package managers right? If that's the case then look at my other Meta Package Manager project:{ "brew": { "available": true, "cli_path": "/opt/homebrew/bin/brew", "errors": [], "executable": true, "fresh": true, "id": "brew", "name": "Homebrew Formulae", "supported": true, "version": "5.0.15-65-g04ece73" }, "cargo": { "available": true, "cli_path": "/opt/homebrew/bin/cargo", "errors": [], "executable": true, "fresh": true, "id": "cargo", "name": "Rust's cargo", "supported": true, "version": "1.93.1" }, "cask": { "available": true, "cli_path": "/opt/homebrew/bin/brew", "errors": [], "executable": true, "fresh": true, "id": "cask", "name": "Homebrew Cask", "supported": true, "version": "5.0.15-65-g04ece73" }, "composer": { "available": false, "cli_path": null, "errors": [], "executable": false, "fresh": false, "id": "composer", "name": "PHP's Composer", "supported": true, "version": null }, "gem": { "available": true, "cli_path": "/usr/bin/gem", "errors": [], "executable": true, "fresh": true, "id": "gem", "name": "Ruby Gems", "supported": true, "version": "3.4.5" }, "mas": { "available": true, "cli_path": "/opt/homebrew/bin/mas", "errors": [], "executable": true, "fresh": true, "id": "mas", "name": "Mac AppStore", "supported": true, "version": "5.2.0" }, "npm": { "available": false, "cli_path": null, "errors": [], "executable": false, "fresh": false, "id": "npm", "name": "Node's npm", "supported": true, "version": null }, "pip": { "available": false, "cli_path": "/Users/kde/code/meta-package-manager/.venv/bin/python3", "errors": [ "/Users/kde/code/meta-package-manager/.venv/bin/python3: No module named pip" ], "executable": true, "fresh": false, "id": "pip", "name": "Pip", "supported": true, "version": null }, "pipx": { "available": false, "cli_path": null, "errors": [], "executable": false, "fresh": false, "id": "pipx", "name": "Pipx", "supported": true, "version": null }, "pkg": { "available": false, "cli_path": null, "errors": [], "executable": false, "fresh": false, "id": "pkg", "name": "FreeBSD System Manager", "supported": true, "version": null }, "steamcmd": { "available": false, "cli_path": null, "errors": [], "executable": false, "fresh": false, "id": "steamcmd", "name": "Valve Steam", "supported": true, "version": null }, "uv": { "available": true, "cli_path": "/opt/homebrew/bin/uv", "errors": [], "executable": true, "fresh": true, "id": "uv", "name": "UV", "supported": true, "version": "0.10.7" }, "uvx": { "available": true, "cli_path": "/opt/homebrew/bin/uv", "errors": [], "executable": true, "fresh": true, "id": "uvx", "name": "UVX", "supported": true, "version": "0.10.7" }, "vscode": { "available": true, "cli_path": "/Applications/Visual Studio Code.app/Contents/Resources/app/bin/code", "errors": [], "executable": true, "fresh": true, "id": "vscode", "name": "Visual Studio Code", "supported": true, "version": "1.109.5" }, "vscodium": { "available": false, "cli_path": null, "errors": [], "executable": false, "fresh": false, "id": "vscodium", "name": "VSCodium", "supported": true, "version": null }, "yarn": { "available": false, "cli_path": "/opt/homebrew/bin/yarn", "errors": [ "env: node: No such file or directory" ], "executable": true, "fresh": false, "id": "yarn", "name": "Node's yarn", "supported": true, "version": null } }johnthagen commentedon Feb 28, 2026
@kdeldycke FYI, to you and others on this thread, the fact you've chosen a GPL licence (https://github.com/kdeldycke/extra-platforms/blob/main/license) does mean that it will not a suitable for many projects that avoid all GPL dependencies.
Thus having this support in a permissively licensed package like
distrois still desirable.kdeldycke commentedon Feb 28, 2026
Thanks for pointing that out. I choose that license by default a long time ago. Do you have examples of projects that can benefits from a change in licence? I am OK to change the licence if it increase adoption.
kdeldycke commentedon Feb 28, 2026
@johnthagen just created an issue at: kdeldycke/extra-platforms#488
kdeldycke commentedon Feb 28, 2026
extra-platforms 11.0.0 has just been released on PyPI under the Apache Software License 2.0: https://pypi.org/project/extra-platforms/