The Cheetah template engine does not work and raises an exception due to not rendering the template before returning it

[arizvisa]

Description of Issue/Question

It seems like the Cheetah template doesn't appear to work. The following exception is raised when trying to use it:

2019-02-19 11:34:09,030 [salt.state       :320 ][ERROR   ][6600] Traceback (most recent call last):
  File "c:\salt\bin\lib\site-packages\salt\utils\templates.py", line 175, in render_tmpl
    if salt.utils.stringutils.to_unicode(output, encoding=SLS_ENCODING).endswith(('\n', os.linesep)):
  File "c:\salt\bin\lib\site-packages\salt\utils\stringutils.py", line 161, in to_unicode
    raise TypeError('expected str or bytearray')
TypeError: expected str or bytearray

Setup

Just get setup to use file.managed with template set to Cheetah.

Steps to Reproduce Issue

One doesn't even need any template variables, just try and use the Cheetah state to render anything and this exception gets raised. This particular code in salt.utils.stringutils hasn't been touched in a year.

Versions Report

Although this is an older version, the relevant code hasn't changed in a year. This seems to be a type error due to a string being assumed when it's an object of some sort. It's in a condition that checks to see if Windows is being used and if so to try and convert it to unicode or something..

Salt Version:
           Salt: 2018.3.3

Dependency Versions:
           cffi: 1.10.0
       cherrypy: 10.2.1
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: 2.1.3
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: Not Installed
        libnacl: 1.6.1
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: 2.17
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)]
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 16.0.3
           RAET: Not Installed
          smmap: 2.0.5
        timelib: 0.2.4
        Tornado: 4.5.1
            ZMQ: 4.1.6

System Versions:
           dist:
         locale: cp1252
        machine: AMD64
        release: 8
         system: Windows
        version: 8 6.2.9200 SP0 Multiprocessor Free

[arizvisa]

It looks like the issue is that the type that's being assumed to be a string is a DynamicallyCompiledCheetahTemplate,

2019-02-19 20:03:19,224 [salt.utils.templates:171 ][ERROR   ][8444] wtf is this type: <class 'DynamicallyCompiledCheetahTemplate.DynamicallyCompiledCheetahTemplate'>
2019-02-19 20:03:19,224 [salt.utils.templates:172 ][ERROR   ][8444] wtf is this type: <DynamicallyCompiledCheetahTemplate.DynamicallyCompiledCheetahTemplate object at 0x049A5810>
2019-02-19 20:03:19,224 [salt.state       :320 ][ERROR   ][8444] Traceback (most recent call last):
  File "c:\salt\bin\lib\site-packages\salt\utils\templates.py", line 175, in render_tmpl
    if salt.utils.stringutils.to_unicode(output, encoding=SLS_ENCODING).endswith(('\n', os.linesep)):
  File "c:\salt\bin\lib\site-packages\salt\utils\stringutils.py", line 161, in to_unicode
    raise TypeError('expected str or bytearray')
TypeError: expected str or bytearray

[arizvisa]

From looking at the code, it looks like the Cheetah template is supposed to have its __str__() method called in order to be able to treat it as a string.

As usual, I guess I'll write up a PR for this one too...

[arizvisa]

Yea. It looks like you need to explicitly call __str__() or __unicode__() to get cheetah to render, and the original author of this code made the assumption that salt.utils.stringutils.to_unicode() will do that. (which it doesn't). One reason why type-checking is good in a large complex project.

[arizvisa]

This is fixed by PR #51718.

[stale]

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.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[arizvisa]

Closing this as it was fixed by PR #51718 which was merged last monthish.