macOS: Update macports, hombrew playbooks to use new pip role

[jhoyt4]

Add new pip role to consolidate python package matinenance for macOS

• Update macport and homebrew to use the new pip role
• update python modules to the latest python dependencies

Macports:

• Update python to 312. Will update to 313 when ansible to updated to allow 313 use

Homebrew:

• Correct perl module installation issue with openssl
• Update fonts packaging nameing convention
• Add mysqlclient as a required package to help with embedded python issus

Addtional work done to clean up with yamllint

[jhoyt4]

@billmeek - This update might need some extra feedback. I added a new pip role to consolidate the python package list for both macports and homebrew. Basically, I'm still using the same logic from before leveraging a python virtual environment, but have made it its own role similar to qt5/qt6.

Long term, as up stream providers stop bundling pip (and maybe perl) modules, it might make sense to move more OSes to a similar mechanism.

If you'd prefer me to go back to the previous method of embedding the pip calls in the macports/homebrew playbooks let me know and I'll make the change.

@garybuhrmaster - I know you update a few playbooks as well, your feedback the pip mechanism would be appreciated.

[billmeek]

@jhoyt4, for now, I'd prefer making the pip role just like the qt5/6 ones. That is, packages get selected on a per distribution basis, not in the roles/pip/tasks/main.yml file. I'm not ready to convert other distributions by removing packages and adding the pip ones.

I like the idea though. There are users that have setup virtual environments already and I'm not clear if this would conflict with them.

[garybuhrmaster]

@garybuhrmaster - I know you update a few playbooks as well, your feedback the pip mechanism would be appreciated.

My initial thoughts:

In Linux distributions, it is generally recommended (and sometimes even required) to not use pip to install additional packages as part of a build for (re)distribution as actual building often does not allow network access (for good reasons), but instead requires one to use the distros specifically available versions of python modules (individuals are, of course, free to do whatever they want, but the rule is you break it, you own it, and mixing python versions and functions can be problematic, and forcing everyone using MythTV to use a dedicated MythTV virtual environments in order use MythTV is going to be differently limiting (I would reject requiring a virtual environment for my use cases)). And each distro uses their own naming convention for their available python installable packages which are not always the pip names.

While I like the idea of one place to identify all python (and perl, and php) packages in one place, I don't think this is a sufficiently flexible way to do it (and as I recall, the logic in some of the roles already does not include some functionality because the distro does not provide it, and likely never will. and the MythTV project does not want to ship additional external sources). Maintaining that distro uniqueness is likely not something that is useful.

As a macOS level only additional role, I don't have an opinion as to whether this is better or worse (as I own no Apple products, nor even know anyone with a macOS product that uses MythTV)

[billmeek]

@jhoyt4, I moved the python packages to pip-macOS.yaml.

[jhoyt4]

@billmeek - Thanks Bill. I'm working and testing in parallel, so I may need to push a few extra updates.

[jhoyt4]

@garybuhrmaster - thanks for the feedback.

The python situation on macOS isn't great with wild variations on the apple installed versions and package support from the macports, homebrew, etc communities. Put plainly, updates are slow, inconsistent, and never have everything needed to get the metadata grabbers working.

Due to this and the desire to continue building app bundles, I needed a clean way to add a consistent embedded python and python site-packages to the app bundle. Most googling paths pointed to "create and embed a virtual environment" as the preferred solution.

I look at the virtual environment as a klugey macOS only solution, but was optimistic that at some point a consolidated list of python packages could help reduce the maintenance burden for everyone (and could be mimicked for perl, php, etc.). Certainly those use cases where the platform has elected to use a different name than those in pip (macports and homebrew are both guilty of this) could be modified on a case by case find and replace basis.

Perhaps a better name for the new role would be python vs pip to encourage movement to a consolidated location?

[jhoyt4]

@billmeek - good point about conflicting with other users virtual environments. For the macOS install, I made sure to specify an install location in the users ~/.mythtv directory which I hoped would be unique enough to avoid any conflicts.

[jhoyt4]

All changes just tested out ok on both my macports and homebrew machines.