Windows support

[petemounce]

Similarly to #26, it would be great to get Windows support. I assume since you welcomed PRs for FreeBSD, you might also welcome ones that add Windows support?

(Obviously, Windows being what it is, I expect this would require more work than FreeBSD... ;) ).

[JackLeo]

What are the missing bits given the existing PR?

[petemounce]

Packages (maybe via chocolatey)?

[JackLeo]

Something like this is more likely:

https://gallery.technet.microsoft.com/scriptcenter/Script-to-get-installed-80cd3798

by the looks of it - digging through the registry should produce the most universal results for base system

Actually querying is quite simple, yet slow - https://stackoverflow.com/a/1482752/558194

wmic product where "Name like '%Office%'" get Name, Version

Works great. Tested in cmd on Windows 10

[petemounce]

I really can't recommend taking a dependency on anything written in VB. wmic probably has a longer deprecation horizon; VB is very legacy.

[JackLeo]

So it's either wmic or inline .NET doing the query. For MVP I would suggest just calling wmic subprocess and retrieving the results then allow someone with deeper Windows knowledge to build further.

The only issue with wmic is that I can't find a list of supported windows versions

[petemounce]

Definitely wmic is the easiest bar, though won't detect portable apps installed via chocolatey. I'd say that's going to be an edge case for systems administration vs consumer users.

[petemounce]

Re: supported - wmi dates back a decade or so at least. Probably fine for the set of likely user population of this library.

[JackLeo]

wmic should detect anything installed via an installer since that puts uninstaller registry entry. Packages like Docker could be both installed via an installer and chocolatey so there might be some edge cases with using them both.

[petemounce]

Having come back to this, I'm now inclined to think that package should assert against package-manager installs only. If software is present on the machine, and the person wants to write tests to assert that, I bet they're almost certainly already aware of chocolatey.

And, @JackLeo is entirely correct, it's possible for a thing to be installed via chocolatey and other means, to completely separate places.

Is it reasonable to make one (initial) chocolatey implementation, and one wmic-based? I saw there's a --format argument to specify which flavour...?

[JackLeo]

I would be inclined to suggest more of a salt approach. package should check all default packaging methods. Any additional ones should be explicit.

Example:

• package - https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html
• pip - https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pip_state.html

I do agree that wmic is not necessarily a packaging mechanism and it might need to be exposed as an explicit check/utility, however, I do not agree that chocolatey could be considered a default method of install/packaging, equally I would not say brew is default one for mac purely based on the fact that is installed by the user and not shipped as part of the OS.

[petemounce]

I definitely agree with "check all default packaging methods".

I suppose I have to agree that chocolatey isn't a default packaging manager. It's still the only credible one, currently, which is why I think it should be treated like a safe default. A newcomer might otherwise miss that, so their goss onboarding experience contains a bit where they need to read a doc before making progress.

[estahn]

349 should help with this.

[petemounce]

380 is trying to add a Windows binary to the releases.

[guillermo-menjivar]

is this still active?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[aelsabbahy]

Goss now provides community supported alpha binaries for windows as per- #585