Support for Windows and Mac OS.

[sethmlarson]

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

[nir0s]

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 distro object 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]

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]

I would suggest changing linux_distribution() to just distribution()? The rest map pretty well actually. All Windows and Mac distributions have a codename, id='windows', 'macos', version, name, pretty name.

[nir0s]

distro.linux_distribution is meant to replace platform.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 of linux_distribution while linux_distribution only returns for linux and distribution returns for any.

[sethmlarson]

I'd say that something like that would work fine. Do we only define that method when on Linux (forcing distro users to check with hasattr) or have linux_distribution throw an error on non-Linux (forcing distro users to catch or check the system type first) or map linux_distribution to distribution just 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]

Um, it seems more natural to me to return empty for linux_distribution if 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 like platform'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]

Oh sure! That can definitely be done. So just a Distribution object that has all empty values.

[FooBarQuaxx]

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]

@FooBarQuaxx Changes to open source projects require contributors willing to give to their free time. Perhaps you could provide a patch?

[Akm0d]

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]

@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]

I was wondering if there is any update on this? Thank you!

[ssbarnea]

@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.

[sethmlarson]

@ssbarnea I am in favor of this, however there's only one member of python-distro that can add new members: @nir0s.

[johnthagen]

For those looking for an alternative for Windows until this is added to distro, see:

• sys.getwindowsversion()