Using six.u() function doesn't work if package name is str and not 'u' #33717
Labels
Bug
broken, incorrect, or confusing behavior
Core
relates to code central or existential to Salt
P2
Priority 2
severity-medium
3rd level, incorrect or bad functionality, confusing and lacks a work around
stale
Milestone
Description of Issue/Question
When investigating the fix for #33605, it because apparent that if a package name with a non-ascii character in it is passed via a state, the state compiler will stack trace and complain about unicode.
Normally the fix for such a situation is to use the
six.u()
function to make sure the unicode string is compatible across Python versions. However, in this case, the package name, even though it contains unicode characters, is being passed as a normal string rather than a unicode string, so usingsix.u()
has no effect and the stack trace is still present.The immediate issue with the Windows package was resolved with the fix in #33670, but there is a greater underlying issue and this fix was just a band-aide. This issue is to track the greater issue revolving around the state name and the
old
ornew
package names that are passed to the state compiler from the pkg modules.Setup
The following state, while it will return False as the package isn't a valid name, should get passed the state compiler. Instead it stacktraces inside the state compiler:
Here is a simple state that doesn't contain non-ascii chars for testing purposes:
Steps to Reproduce Issue
Run the state above with
salt-call --local state.sls non-ascii
:Here's what the second state looks like when a state doesn't exist, but there are no non-ascii chars (on Ubuntu):
Versions Report
(Provided by running
salt --versions-report
. Please also mention any differences in master/minion versions.)ping @s0undt3ch
The text was updated successfully, but these errors were encountered: