The docs are failing to build with the following error:
Failed to import 'salt.cloud.clouds.azurearm'; the module executes
module level statement and it might call sys.exit().
The "cleanup" done in 982c55cf broke docs builds on develop. It made a
number of unnecessary changes, for puzzling reasons. The `__opts__` and
`__utils__` dunders do not need to be manually created, they're present
automagically courtesy of the loader.
This removes all of the module level calls and replaces the helpers with
calls to the corresponding functions from the `__utils__` dunder.
When the Kubernetes client is not installed, the import of
salt.modules.kubernetes will still succeed, but HAS_LIBS will be set to
False (since the library import will be covered by a try-except clause).
Therefore expect the salt.modules.kubernetes to always succeed and check
kubernetes.HAS_LIBS instead for the presence of the kubernetes library.
Signed-off-by: Benjamin Drung <benjamin.drung@profitbricks.com>
To explain this change, it's necessary to first understand the history
of `object_hook` usage in Salt.
Initially, the function used as the object hook wherever we used it was
(incorrectly) named `encode_dict`, despite the fact that the code was
*decoding* the contents of the dictionary to unicode. This function was
renamed to `decode_dict`, and a counterpart which *actually* encodes was
put in its place. At this time *most* of the `object_hook` usage was
changed so that `decode_dict` was used, but some references were left
using `encode_dict` (likely because I wasn't sure whether or not
changing them would break things).
However, if the desire is to have unicode values after loading JSON,
there is actually no need to use an object hook, since loading JSON in
Python always produces unicode results even with a POSIX locale!
[root@2719cd6224d3 /]# locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
[root@2719cd6224d3 /]# python
Python 2.7.5 (default, Nov 6 2016, 00:28:07)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.loads('{"foo": "bar"}')
{u'foo': u'bar'}
>>> json.loads('{"foo": "Д"}')
{u'foo': u'\u0414'}
>>>
Therefore, this commit removes all `object_hook` usage where
`decode_dict` was the hook being used, since it is redundant. It also
removes one use of `encode_dict` as an object hook that was still left
in code used by salt-thin.
The only `object_hook` left is in some of our ioflo code. I left the
`encode_dict` there, but _only for Python 2_, because if I remember
correctly ioflo needs str types, and encoding a string in Python 2
produces a str type.
I used the incorrect version in my upstream bug workaround in #45892,
I missed that there was a 0.26.3 released before the bugfix was made.
This corrects that, and also fixes an incomplete comment that trailed
off in the middle of the sentence.
tornado needs to be >= 4.2.1, but less that 5.0.
Tornado 5.0 is introducing backwards-incompatible changes. Therefore,
we need to pin the version of tornado in base.txt until we can fix
supporting Tornado 5.0 in Salt.
Refs #45790
tornado needs to be >= 4.2.1, but less that 5.0.
Tornado 5.0 is introducing backwards-incompatible changes. Therefore,
we need to pin the version of tornado in base.txt until we can fix
supporting Tornado 5.0 in Salt.
Refs #45790
