Mailing List Archive

Branch: refs/heads/master
Home: https://github.com/MythTV/mythtv
Commit: af345e226b666c53bc802b6f2ac07e5dd5c4778e
https://github.com/MythTV/mythtv/commit/af345e226b666c53bc802b6f2ac07e5dd5c4778e
Author: Eli Schwartz <eschwartz93@gmail.com>
Date: 2024-01-08 (Mon, 08 Jan 2024)

Changed paths:
M .github/workflows/buildmaster.yml
M mythtv/configure
M mythtv/programs/scripts/hardwareprofile/smolt.py

Log Message:
-----------
hardwareprofile: remove external dependency on simplejson

This uses the requests module and converts requests responses to json
using requests' own `.json()` method on responses. For incomprehensible
reasons, requests has spent about a decade using either simplejson or
the standard library's json module more or less at will, and returning
either one or the other exception types. They don't know why they use
simplejson, we don't know why they use simplejson. In requests 3 (which
will be released in the Year Of The Linux Desktop or when pigs fly,
whichever one comes later) simplejson is dropped entirely.

There are innumerable issues discussing the problem on the requests
bugtracker, with the general consensus being that it's better to
randomly return either one of two different libraries and two different
library return types in errors -- because it was historically done that
way and people might be depending on it. ??????

Bugs:

https://github.com/psf/requests/pull/710
https://github.com/psf/requests/pull/2516
https://github.com/psf/requests/issues/3052
https://github.com/psf/requests/issues/4169
https://github.com/psf/requests/issues/4842
https://github.com/psf/requests/issues/5794
https://github.com/psf/requests/issues/6084

The awkward workaround is to guarantee that requests' silent behavior of
using simplejson *if it is installed* is forcibly triggered by forcibly
depending on simplejson, and then catching the simplejson exception.

The better solution here is pretty simple: do not rely on the requests
module's automatic json conversion, this is as simple as using the
already-imported json module and calling json.loads() on the retrieved
content.

Fixes: 1df343e9ab7defa284a73390210a65cf2112f17e
Reimplements: bb154a843b737cc3ad8c1a45fa04a1a3609aff05


Commit: 4b5eac8ae915377ced9f782eba4d131ecde12182
https://github.com/MythTV/mythtv/commit/4b5eac8ae915377ced9f782eba4d131ecde12182
Author: Eli Schwartz <eschwartz93@gmail.com>
Date: 2024-01-08 (Mon, 08 Jan 2024)

Changed paths:
M mythtv/configure
M mythtv/programs/scripts/hardwareprofile/MultipartPostHandler.py
M mythtv/programs/scripts/hardwareprofile/distros/mythtv_data/request.py
M mythtv/programs/scripts/hardwareprofile/distros/mythtv_data/uuiddb.py
M mythtv/programs/scripts/hardwareprofile/hwdata.py
M mythtv/programs/scripts/hardwareprofile/os_detect.py
M mythtv/programs/scripts/hardwareprofile/request.py
M mythtv/programs/scripts/hardwareprofile/scan.py
M mythtv/programs/scripts/hardwareprofile/uuiddb.py

Log Message:
-----------
hardwareprofile: remove ancient "future" compatibility library for python2

Ironically, for a package that was intended to provide portability
between python2 and python3, it is broken with python 3.12. A better
library to use in all cases is "six".

However, mythtv requires python 3.8 for a while now. Using
"future.standard_library" is a no-op other than costing a pointless
import and being troublesome to actually install.

The hacky copy of six.with_metaclass included in "future" is rewritten
to use the pure python3 form of a metaclass.


Compare: https://github.com/MythTV/mythtv/compare/b7092c00c95e...4b5eac8ae915
_______________________________________________
mythtv-commits mailing list
mythtv-commits@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-commits