saltstack/salt — pull request #5335 by mprymek (2013-05-31 11:21:47+00:00)
Title: Try to decode package names with os' preferred encoding

[This is just a proposed patch, please read the description and "P.S." carefully and decide for yourself if it's to be merged or not]

DESCRIPTION:
Names of the installed packages on Windows should be decoded using Windows' default encoding.

win_pkg module retrieves installed package names from two sources:
1. Windows registry (function _get_reg_software)
2. msi products db (function _get_msi_software)
This patch only affect the first source.

RATIONALE:
AFAIK strings in Windows registry don't have any encoding attached. You can install package A with name encoded in encoding eA and simultaneously package B with eB. So the names of the packages in registry don't have consistent encoding _in principle_ (AFAIK). Regardless, we can do _best-effort decoding_ of the names.

I think we can suppose that the packages installed are mostly in 1. plain ascii ("english") 2. in the same encoding as the os' default encoding. (e.g. user of Czech windows will have mostly english- and czech-named software and names are encoded in the usual os' encoding).

The decoding using suggested encoding is just _tried_. If it fails, name is silently left untouched.

RESULT:
# salt pkg.list_pkgs
without patch: http://i.imgur.com/aPVJbEB.png
with patch: http://i.imgur.com/vIOd3zL.png
(this is correct Czech spelling)

P.S.:
1. I'm not 100% sure if the method used in this patch (locale.getpreferredencoding()) is the best possible approach. Feel free to suggest a better solution.
2. The above-mentioned function _get_msi_software() decode msi-package names to plain ascii (see line 252). I don't understand rationale behind that. The function used for retrieval of the package names returns _unicode_ and the names should be therefore correctly encoded. I don't understand why to convert correct unicode strings to plain ascii. This corrupts original package names and can break some comparisons, auditing etc. Anyway this is _not consistent_ with the result get from _get_reg_software which (without this proposed patch) returns arbitrarily-encoded not-unicode strings. Hence, the result would be different if you install the same package using msi or without which is IMHO not expected behavior.